Job titles and design. It’s an interesting, never-ending quest for clarity.

I started my design career as a graphic designer. My boss didn’t even know what to call it, honestly. For him, it was: I need someone who makes graphic work. And I started without a degree, so I didn’t know either. Graphic designer. Whatever. I relabeled it later when cleaning up my resume to visual designer—because in essence I was focused on the visual side of things. Wrong icons, PowerPoints, booth designs, brochure work, DTP, stuff like that.

But I was getting more and more involved in interface design. So I started studying communication and multimedia design. At that point, it wasn’t necessarily about chasing a job title. I did have a subject called interaction design—one of the best subjects I had, taught by one of my greatest teachers, Ferry den Dopper. He really showed the deeper layers of designing software. And that’s pretty much where it started. From visual designer, I became an interaction designer.

At the time, that was the common way to look at UX design. UX design wasn’t even the label yet. Interaction design was common, and so was user researcher. Then UX design became a thing. So I relabeled again. I became a UX designer, and later a UX/UI designer—because most hiring managers had no clue. Companies had no clue. Our whole design community was just trying to figure it out. UI designers were moving into UX work. User researchers were suddenly responsible for visual design too. Interaction design became old school, and information architect became an even more dying trade. Eventually we became experience designers, design systems engineers or product designers.

The titles kept shifting.

And more and more, the focus moved to output: great-looking user experiences. I noticed—working in very complex environments—that UX researchers were still fighting in boardrooms for budget just to talk to users. But in the end, the systems took over.

What has happened now is that those systems are powered by AI to generate the screens as well. Once the tokens are in place, once the rules and guidelines are set, generation becomes easier. The output we drifted toward is no longer what we need humans for.

The designers doing well in this shift are the ones going back to the roots. Back to the essence of design.

Information architecture.

AI Needs Good IA

Everyone is prompting now. Developers, designers, business owners and product managers. You describe what you want and the system generates it. Fast and impressive.

But most people just throw raw information at AI and hope for the best. No structure, no curation, no defined relationships. Just input and whatever comes out.

Think about how your brain filters sound. Walking down the street, your ears pick up everything—traffic, a dog barking, voices around you. But your brain decides what to hear. Not because it has better microphones. Because it has context. It knows the car passing is a risk for the kid holding your hand. It knows the dog might be your neighbor’s and you want to say hi. Your brain knows what matters because it understands relationships.

That’s information architecture. Built into human intelligence by default.

AI doesn’t have that by default. It has to be given it. When you dump raw, unstructured information into a chat window, the model does its best—but its best is a statistical average. A plausible answer built on assumptions. Without structure, without relationships, without context, there’s no way to know what actually matters.

Great intelligence—artificial or human—runs on well-structured information.

How to Architect Information

Information architecture is a serious discipline. There are entire books, frameworks and careers built fully around it. I won’t be covering all of that here.

What I want to cover is where to start. Two things you can do today that will immediately improve the quality of your AI output, your designs and your systems.

The essence of design. Drawing boxes and drawing lines.

I call them reframe and relate.

Reframe

Every piece of information has a name. Most of the time, you don’t even realize it. You chose a label that felt logical or felt obvious, and it stuck. Now the whole team uses it, it’s in the system, it’s in the class naming, it’s everywhere. And now the AI is getting trained on it too.

Bad names become a bad foundation.

Reframing means stopping and asking: what is this, actually? What do we call it, and does that name carry the right meaning for everyone using it? This is what reframing is about—consistent vocabulary, shared definitions and metadata that makes information findable, searchable and more important than ever: machine-readable.

Take a simple example from an engineering dashboard. A field shows a value from a sensor on a piece of equipment. Someone called it “reading” when they built it. It made sense at the time. But across the system, the same concept gets called “value” in one place, “measurement” in another and “output” in a third. The AI getting trained on this data has no way of knowing these are the same thing. Neither does the new engineer onboarding. Neither does the search index.

Reframing means stopping and agreeing: this is a measurement. That’s what we call it, everywhere, always. You update the label, the metadata, the tags. Now the system can find it. Now the AI can reason about it correctly.

But a measurement on its own still means nothing.

Relate

Once the boxes are named and defined correctly, it’s time to draw the lines.

That measurement only makes sense in relation to the equipment it came from, the threshold it’s being compared against and the operational phase it belongs to. A vibration reading of 4.2 during drilling startup means something completely different than the same reading during steady-state operation. The number is the same. The meaning is not.

When you relate that measurement to its context, you give the AI what it needs to interpret correctly. Not guess. Interpret.

That’s the difference between structured information and raw data.

How does this connect to that? Why? In what order and with what priority? Those relationships turn a collection of content into a system that actually makes sense. This is where most people stop. The taxonomy is solid, the data is curated and they call it done. But without the logic that connects one thing to another, the structure is static. It doesn’t move when applied.

Information that relates is information that works—for users navigating a product, for a team maintaining a system and for an AI that needs to understand not just what things are but how they belong together.

Draw the boxes. Connect them. That’s your architecture.

Closure

Information architecture never went away. It got buried under the pressure of shipping more screens. We knew this once. Then we let it go. Now it matters again.

Now the screens are being generated. We finally have the time back to think, to provide structure and to build real foundations.

This is old school. Designers and developers were doing this long before AI made it a necessity. If you have that background, dust it off. This is your differentiator.

And if you’re new to it, start simple. Two questions before you prompt, before you build anything:

• What are the boxes? Reframe them.
• What are the lines? Relate them.

That’s your foundation. That’s how you make AI work better. And that’s how your work gets better too.

Blazor has become a serious platform for building modern web applications with .NET. As the framework has matured, commercial UI component libraries have become an important part of the Blazor development experience.

Instead of building every Grid, Chart, Scheduler, Form, Editor, and navigation component from scratch, teams can rely on mature component suites to accelerate development, improve UI quality and reduce long-term maintenance effort. Two of the most common options for Blazor development are Progress Telerik UI for Blazor and Syncfusion Blazor.

Both are mature. Both provide large component collections, commercial support, documentation, examples and tooling for .NET developers. Both can be used to build complex business applications.

The decision is rarely about whether one product is objectively “better.” A more useful question is: “Which library better matches the way your team builds, maintains, upgrades and scales Blazor applications over time?”

At a high level, Syncfusion Blazor is attractive for teams that want a very broad component catalog, access to many specialized controls and a Community License for qualifying users. Telerik UI for Blazor is a strong fit for teams that value a cohesive developer experience, predictable APIs, strong theming workflows, product polish, support reputation and long-term maintainability.

This comparison looks at both products through practical evaluation criteria: onboarding, component coverage, grid capabilities, theming, accessibility, performance, support, AI readiness and long-term project fit.

Quick Decision Summary

Choose Telerik UI for Blazor if…

• You are building a long-lived application that will be maintained for several years.
• Multiple developers or product teams will contribute to the same UI codebase.
• You value predictable APIs and standardized implementation patterns.
• You need strong theming, design-token management or designer-developer collaboration.
• You care about upgrade experience, support quality and long-term maintainability.
• You want a component suite that is easy for both developers and AI coding assistants to reason about.

Key Differences at a Glance

What Most Teams Eventually Optimize For

When teams first compare component libraries, they usually start with feature lists.

That makes sense. Component count, available controls, Grid features, Scheduler options, chart types, templates, exporting and documentation examples are easy to compare.

But once a Blazor application moves into production, different questions become more important:

• How easy is the application to maintain?
• Can new developers understand the UI code quickly?
• Are component APIs predictable?
• How painful are upgrades?
• Can we apply the same branding across multiple applications?
• Can designers and developers work from the same design system?
• How reliable is support when something breaks?
• Can AI coding assistants generate correct and maintainable UI code?

This is where the distinction between breadth and cohesion matters.

Syncfusion has a strong case when a team wants access to a broad collection of components, related document libraries and specialized controls. Telerik has a very strong case when a team wants a more unified development model, mature theming workflows and a polished component experience across the core UI scenarios that most business applications depend on.

Neither priority is wrong. The better choice depends on what your team values most.

Time to First Value

Feature comparisons are useful, but the first developer experience is usually more practical:

• How do I install the package?
• How do I configure licensing?
• How do I set up NuGet access?
• How do I create the first Blazor project?
• How quickly can I render a real component?
• How many manual steps are required before I can start evaluating the library?

This is where time to first value becomes important.

Time to First Value: Telerik UI for Blazor

Telerik puts a strong emphasis on guided onboarding. The product experience includes getting-started documentation, templates, licensing guidance, CLI-based workflows and integration with Telerik tooling.

Telerik focuses heavily on onboarding and guided setup, and this includes:

• Structured getting-started documentation
• Starter project guidance
• Project templates and configuration assistance
• Consistent setup patterns across components

The Telerik CLI can help reduce setup friction by assisting with project creation, package configuration, licensing-related setup, templates and related tooling.

This matters because early evaluation is not only about installing a NuGet package. It is about reducing the number of small setup decisions that slow teams down before they can assess the actual components.

The setup becomes as simple as:

For larger teams, this kind of guided setup can be useful because new developers do not need to rediscover the same configuration steps independently.

Time to First Value: Syncfusion Blazor

Syncfusion also has a strong onboarding story. Its ecosystem includes product documentation, sample applications and a large collection of examples. The Syncfusion Blazor samples repository describes demos for Blazor Server and Blazor WebAssembly apps, including project files targeting modern .NET versions.

That breadth of examples can be valuable when a developer is looking for a specific scenario or specialized component behavior.

Time-to-First-Value Takeaway

For a small proof of concept, both products can get developers started quickly.

The advantage of Telerik UI is more about guided setup and a cohesive path from installation to production-style usage. Syncfusion’s advantage is the large ecosystem of samples.

Component Coverage

Component count is one of the most visible comparison points.

Syncfusion Blazor is known for broad component coverage. Its Community License page describes access to 145+ Blazor components for eligible users and organizations. Syncfusion’s broader product line also includes UI components, document SDKs and standalone UI SDKs under the Community License description.

That breadth is a legitimate advantage. Teams that need niche controls, document processing capabilities, PDF-related libraries, Office document support or specialized UI scenarios may find Syncfusion difficult to overlook.

Telerik UI for Blazor takes a somewhat different approach. It provides a large suite of core Blazor components, but its strongest value proposition is not simply the number of controls. Telerik UI is strongest when the application depends heavily on polished core components such as Grid, Charts, Scheduler, Forms, Inputs, Editors, Layout, Navigation, Upload and theming.

For many business applications, both libraries cover the essential requirements. The practical difference is often not “Does a component exist?” but:

• How predictable is it to configure?
• Does it follow familiar patterns from other components in the same suite?
• Does documentation match real development scenarios?
• Is the component easy to theme and maintain?
• Does it fit into a shared UI platform?

Component Coverage Takeaway

Syncfusion has the advantage in overall breadth and specialized coverage.

Telerik has the advantage when teams want a cohesive suite focused on core business application scenarios, polished UI behavior and maintainable implementation patterns.

The Grid: The Component That Often Decides the Evaluation

If one component influences UI library decisions more than any other, it is usually the grid.

Business applications spend a large amount of time displaying, filtering, grouping, sorting, editing, exporting and analyzing data. For many teams, the grid is not just one component. It is the center of the application.

Both Telerik UI for Blazor and Syncfusion Blazor provide capable Grid components with support for common business scenarios such as:

• Sorting
• Filtering
• Grouping
• Paging
• Virtualization
• Inline editing
• Batch editing
• Templates
• Aggregates
• Exporting
• Hierarchical data
• Large dataset scenarios

Both vendors can support serious data-heavy applications. In practice, grid performance depends not only on the component itself but also on data access strategy, rendering mode, server communication, virtualization configuration and application architecture.

Telerik UI for Blazor Grid

The Telerik UI for Blazor Grid is strongest when teams care about a polished and predictable implementation model.

The main advantages are not only feature availability, but how the Grid fits into the broader development experience:

• Predictable configuration patterns
• Strong template support
• Familiar event and data-binding approaches
• Alignment with the rest of the Telerik component suite
• Accessibility-specific documentation
• A mature experience for common business data scenarios

Telerik Grid accessibility is WCAG 2.2 AA and Section 508 compliant, follows WAI-ARIA best practices for keyboard navigation and is tested with popular screen readers. That is a concrete point worth considering for teams building applications with formal accessibility requirements.

Syncfusion Blazor Grid

The Syncfusion Grid is also highly capable and has a broad feature surface. It is particularly attractive when teams need extensive configuration options or specialized behaviors.

Syncfusion’s Grid supports accessibility standards including ADA, Section 508, WCAG 2.2 and ARIA roles, with details on screen reader support, RTL support, color contrast, mobile device support, keyboard navigation and Axe-core validation.

Grid Takeaway

Both Grids are mature and capable.

Syncfusion’s Grid stands out for broad functionality and configurability. The Telerik Grid stands out for a polished developer experience, accessibility documentation and a usage model that tends to fit well into long-lived applications with multiple contributors.

If your evaluation is based on a specific Grid feature, test that feature in both products. If your evaluation is based on long-term maintainability, onboarding, accessibility and shared implementation patterns, Telerik deserves stronger consideration.

Scheduler, Charts and Dashboards

After the Grid, Scheduler and Charts are often among the most important components in business applications.

Scheduler

Both Telerik and Syncfusion support common scheduling scenarios such as:

• Day, week and month views
• Recurring events
• Resource grouping
• Drag-and-drop editing
• Custom templates
• Business calendar scenarios

Syncfusion is attractive when the team wants broad scenario coverage and many examples.

Telerik is attractive when the Blazor Scheduler needs to feel like part of the same UI platform as the Grid, Forms, Inputs, Dialogs, Charts and navigation components.

Charts and Dashboards

Both libraries provide charting capabilities suitable for dashboards, reporting UIs, KPI tracking, analytics screens and business intelligence-style interfaces.

The distinction is less about whether common chart types exist and more about the surrounding workflow:

• How easily can charts be themed?
• Can they follow the same visual system as the rest of the app?
• Can multiple teams reuse the same design language?
• Can dashboard screens stay visually aligned over time?

This is where the Telerik theming story becomes especially relevant.

Theming and Design-System Governance

Theming is often underestimated during evaluations.

At the start of a project, teams usually focus on functionality. Later, especially in long-lived applications, theming becomes a product and architecture concern.

Questions start to appear:

• Can we align components with our brand?
• Can designers and developers collaborate without translating everything manually?
• Can we reuse themes across multiple applications?
• Can we manage design tokens centrally?
• Can we support light and dark modes?
• Can we avoid one-off CSS overrides that become hard to maintain?
• Can we update the visual language without rewriting large parts of the UI?

This is one of Progress Telerik UI’s clearest differentiators.

Progress Telerik ThemeBuilder

Progress Telerik ThemeBuilder is a SaaS tool that enables teams to create custom themes and preview how they affect component appearance. It can generate a CSS file that can be used in a Blazor app instead of a built-in theme.

ThemeBuilder also supports capabilities that matter in design-system driven organizations, including:

• Atomic customization
• CSS/SASS variables
• Custom HTML support
• Figma integration
• Theme modes and built-in themes
• Custom fonts and iconography
• Project sharing
• Version control
• Collaboration and user access rights

This is more than visual customization. It helps teams create a shared styling workflow between design and engineering.

For organizations with multiple product teams, this can reduce duplicated CSS work, prevent visual drift between applications and make brand updates easier to manage.

Syncfusion Customization

Syncfusion also provides styling and customization options. For many teams, those capabilities will be enough.

However, if centralized design-system governance is a major requirement, Progress Telerik ThemeBuilder gives it a particularly strong position.

Theming Takeaway

Both libraries can be customized.

Telerik has a clearer advantage when teams need design tokens, Figma-related workflows, centralized branding, visual governance and reusable themes across multiple applications.

Blazor App Accessibility

Accessibility should be part of any serious UI library evaluation.

Teams building applications for public sector, healthcare, finance, education, government or large internal platforms often need to consider:

• WCAG
• Section 508
• Keyboard navigation
• Screen reader support
• WAI-ARIA roles and attributes
• Color contrast
• Accessible interaction alternatives
• Accessibility conformance documentation

Telerik Accessibility

Telerik UI for Blazor provides an accessibility compliance table that lists WCAG 2.2 compliance levels for individual components. Progress Telerik also provides an Accessibility Conformance Report through VPAT.

For the Grid specifically, Telerik documents WCAG 2.2 AA and Section 508 compliance, WAI-ARIA best practices, keyboard navigation, and screen reader testing.

Syncfusion Accessibility

Syncfusion documents accessibility support for Blazor components, including WAI-ARIA, WCAG 2.2, Section 508, keyboard navigation, screen reader support, RTL support and color contrast considerations.

Syncfusion’s DataGrid accessibility documentation also provides a detailed view of supported standards and limitations for complex interactions.

Accessibility Takeaway

Both vendors take accessibility seriously and provide documentation around standards and component behavior.

The Telerik component-level compliance table and documented Grid compliance are helpful for teams that need formal accessibility evidence. Syncfusion also provides broad accessibility documentation, including detailed DataGrid accessibility coverage.

For accessibility-sensitive applications, the best approach is to test the exact components and configurations your application will use.

Support, Documentation and Learning Resources

Support quality is hard to capture in a comparison table, but it often becomes critical after adoption.

During a trial, teams should evaluate:

• How quickly developers find answers in documentation
• Whether examples match real scenarios
• How clear upgrade notes are
• How support handles complex issues
• Whether feedback and bug reports are visible
• Whether the vendor provides practical guidance beyond simple demos

Telerik UI for Blazor Support

Progress Telerik has a long-standing reputation in the ecosystem for polished components, detailed documentation, active forums, feedback channels and strong support. That reputation is one of the reasons Telerik UI is often favored by teams building long-lived applications.

This should still be validated during evaluation. The best support test is not reading a marketing page. It is submitting realistic trial questions and measuring how useful the answers are.

Syncfusion Blazor Support

Syncfusion also provides commercial support, documentation, samples and a large knowledge base. Its broad ecosystem can be helpful when developers are searching for examples across many controls and scenarios.

Syncfusion’s large sample repository is especially useful when teams want to inspect working examples and compare usage across components.

Support Takeaway

Both vendors provide serious support and learning resources.

Telerik UI is often especially attractive for teams that prioritize product polish, support confidence and long-term UI quality. Syncfusion is strong for teams that value broad documentation coverage, many samples and a large ecosystem.

Product Quality, Stability and Upgrade Experience

Product quality is more than whether a component works in a demo.

For long-lived applications, quality usually means:

• Stable APIs
• Clear documentation
• Predictable behavior
• Accessibility guidance
• Reliable release notes
• Manageable upgrades
• Good support for modern .NET versions
• Transparent handling of bug fixes and breaking changes
• Similar concepts across related components

This is where the Telerik UI value proposition becomes stronger. Its advantage is not only that the components are polished, but that the suite tends to feel like a coherent product rather than a collection of unrelated controls.

That can reduce cognitive load for teams. Developers who learn common Telerik concepts in one component often find similar ideas elsewhere in the suite.

Syncfusion’s broader catalog is valuable, but naturally creates a larger surface area to learn, test and govern. That tradeoff may be completely acceptable if the team needs the additional breadth.

Upgrade Experience Takeaway

For short-lived apps, upgrade experience may not matter much.

For applications expected to live for several years, upgrade predictability and maintainable implementation patterns become important. Telerik UI is particularly compelling for teams that prioritize those concerns.

AI Readiness and Agentic Development

A few years ago, component library evaluations focused primarily on features, performance and support. Today, many teams are adding another criterion to their evaluation:

How well does the platform integrate with AI-assisted development workflows?

The discussion is no longer limited to AI-powered components. Developers increasingly expect AI tools that can help generate interfaces, configure components, validate code, enforce design-system rules and accelerate application development.

Progress Telerik AI Approach

Progress Telerik has invested in AI-assisted development across several areas of the product ecosystem, combining UI components, AI-powered tooling and agentic workflows into a more complete development experience.

The foundation of this effort is the Telerik AI Coding Assistant, which integrates directly into developer workflows through IDE-based experiences, GitHub Copilot extensions, and MCP-based tooling. The assistant can help generate Telerik UI for Blazor code, configure components, scaffold common scenarios, generate sample data and provide implementation guidance using Telerik-specific knowledge rather than generic web examples.

Beyond code generation, Progress Telerik has introduced an Agentic UI Generator that uses a collection of specialized assistants working together through an MCP-based architecture. Rather than generating isolated snippets, it can help create complete pages, dashboards, layouts and component configurations while following Telerik component patterns and design-system guidance.

The platform includes specialized assistants for:

• Page and UI generation
• Component selection and configuration
• Layout creation
• Styling and theming
• Icons and visual assets
• Accessibility guidance
• Validation and quality checks
• Project onboarding and setup workflows

These capabilities are orchestrated through the Agentic UI Generator, allowing developers to work at a higher level of abstraction when creating Blazor applications.

Telerik AI Plugins, MCP and Development Tools

One notable aspect of the Telerik AI strategy is the focus on developer tools rather than only AI-enabled components.

The Telerik MCP-based tooling includes plugin capabilities for:


This allows AI tools to work with Telerik-specific knowledge instead of relying solely on generic LLM training data, which can help reduce incorrect component usage and configuration errors.

In addition, Telerik provides AI-enhanced capabilities within its component ecosystem, including AI-powered chat experiences, semantic search scenarios, AI-assisted data operations, AI integrations within Grid and Editor components, WebMCP support, and integration scenarios involving technologies such as A2UI, AG-UI and Microsoft Agent Framework.

Syncfusion AI Position

Syncfusion is also actively investing in AI-based developer experiences and provides AI-related features, assistants and tooling across its ecosystem. Like Progress Telerik, Syncfusion is exploring AI-assisted development workflows and has published AI-related resources and component skills for developers working with its platform.

One of Syncfusion’s broader advantages remains the size of its overall ecosystem, which includes a large collection of UI components, document processing libraries and developer tools that can participate in AI-assisted workflows.

AI Readiness Takeaway

Which platform has the stronger AI story? Today, both Progress Telerik and Syncfusion are investing in AI.

The difference is less about whether AI capabilities exist and more about where the investment is focused.

Syncfusion’s strength comes from the breadth of its ecosystem and the large number of controls, libraries, and scenarios available to developers.

Telerik UI’s strength comes from providing an increasingly connected AI development experience that spans:

• AI Coding Assistant
• Agentic UI Generator
• MCP-based development tooling
• Specialized AI assistants
• Validation workflows
• Accessibility guidance
• Design-system alignment
• AI-enhanced components and features

For teams looking beyond AI-powered controls and toward AI-assisted UI development, Telerik currently offers one of the more comprehensive AI stories available in the Blazor ecosystem. The combination of UI generation, component-aware assistants, validation tooling, theming guidance and MCP integration makes the AI capabilities feel like part of the overall developer workflow rather than a collection of isolated features.

Where Telerik Has a Clear Advantage

Telerik is strongest when the team cares less about maximizing the catalog and more about building a maintainable UI platform.

Telerik is particularly compelling when:

• The application will live for several years.
• Multiple developers or product teams will work in the same codebase.
• The Grid, Forms, Charts, Scheduler and layout components need to feel cohesive.
• Design-system governance matters.
• The team wants strong theming workflows through ThemeBuilder.
• Accessibility evidence is important.
• Support confidence is a major factor.
• AI-assisted development is becoming part of the engineering workflow.

The clearest Telerik differentiator is ThemeBuilder. Its support for visual customization, variables, Figma integration, theme modes, custom fonts, project sharing, version control and collaboration makes it especially useful for teams that need a structured design-to-development workflow.

Pros and Cons

Telerik UI for Blazor

Syncfusion Blazor

Decision Framework

Telerik UI for Blazor is likely the better fit if…

1. The application will be maintained for several years.
2. Multiple developers or teams will contribute to the UI.
3. You need a shared design system.
4. The Grid is central to your application.
5. Accessibility documentation is important.
6. You want a polished and cohesive development experience.
7. Support confidence is part of the buying decision.
8. You expect AI-assisted development to become more important.
9. You value maintainability more than raw component count.

Syncfusion Blazor is likely the better fit if…

1. You need the large component catalog.
2. You need niche components.
3. The Community License applies to you.
4. Your team is comfortable managing a larger API surface.
5. Your evaluation is primarily driven by breadth and feature availability.

Final Verdict

If your primary goal is maximizing the number of available controls, accessing specialized components, benefiting from a Community License, Syncfusion Blazor is difficult to overlook.

If your priority is building a long-lived Blazor application with a cohesive developer experience, strong theming, accessibility documentation, support confidence, predictable implementation patterns and maintainable UI architecture, Telerik UI for Blazor offers a very compelling value proposition.

The choice comes down to what your team wants to optimize for. Feature breadth matters during evaluation. Maintainability matters in production.

For teams building applications that need to scale across developers, products, themes, accessibility requirements, and future AI-assisted workflows, Telerik UI for Blazor stands out as the stronger long-term choice—not because Syncfusion is weak, but because Telerik UI for Blazor’s strengths align especially well with the needs of structured, design-system driven, maintainable Blazor development.

Try Telerik UI for Blazor

In this post, I want to talk about a choice most teams are making without realizing it: delegating work to AI agents when they should be automating it deterministically, and the financial cliff that choice creates.

Image generated with AI

We are leaving the golden age of cheap tokens. The era where companies handed AI a blank check and called it innovation is ending. Reports across the industry tell the same story: budgets consumed in months instead of years, teams scrambling to explain runaway costs and executives quietly asking whether the return ever justified the spending. AI agents, the ones that loop, retry, reason and call themselves back, turned out to be remarkably efficient at one thing: burning through tokens.

We talk about the current AI cycle resembling a bubble. And although it has not fully burst yet, the air is leaving. What remains will be expensive. The professionals who built their entire workflow on token-hungry agents will be the first to feel the squeeze.

The Difference Nobody Talks About

There is a fundamental distinction between the two approaches that the industry keeps conflating into a single term.

An AI agent is a system that receives a goal, reasons about it, makes decisions at runtime and consumes tokens with every step. It is powerful. It is also unpredictable in cost because you are paying for the machine to think every time it runs.

Deterministic automation is a system that analyzes a known structure, applies fixed rules and produces a predictable output, without tokens or runtime reasoning. That will reduce the surprises on your invoice.

Both use intelligence. One front-loads it. The intelligence lives in the design, not in the execution. I call it deterministic AI: a system shaped by years of architectural thinking, where the machine does not need to reason because the reasoning already happened when you built it.

The most intelligent system is the one that does not need to think at runtime.

What I Built Instead

I spent years building a platform that generates entire SaaS applications from a data structure. Not a prototype, and not a scaffold. A complete, production-grade system: backend in .NET, frontend in React, data-first, mobile-first, unit test coverage on both sides, observability baked in with Prometheus, Loki and Tempo, and ready-made Grafana dashboard templates. Roughly 60 files per entity, generated deterministically from the shape of your data.

When a client asked me for a Micro CRM to be delivered overnight, I did not open an AI chat and start prompting. I ran my automation. In under eight hours, including three hours of database design, I made it myself. It was done. Backend, frontend, tests, monitoring. Everything in less than eight hours.

And with zero tokens consumed. (That also cuts unpredictable costs.) The result was identical to what I would have delivered if I had spent a week writing it by hand, because the automation encodes years of decisions I already made.

This is not anti-AI. This is anti-waste.

Where AI Still Earns Its Place

I am not arguing against AI. I use it. But I use it surgically, not as a crutch.

My automation already had a structure designed around C# interfaces, built specifically so that an AI model could understand and navigate the codebase. When I needed to expand unit test coverage, I pointed an AI coding assistant at the existing tests and had it generate new ones that followed the same patterns. I ran it for about six hours over two days. The cost was around $20 in tokens.

Twenty dollars. A manageable, traceable cost for a well-scoped task. But here is the part that matters: I had set a spending limit. Without it, that same task could have spiraled into hundreds, maybe thousands. And that, I believe, is exactly where companies bleeding money on AI are failing: not in choosing to use it, but in using it without boundaries.

I also explored running a custom LLM locally using Ollama and integrating it with my coding environment. It offers unlimited token usage at zero marginal cost, but it demands serious hardware: a GPU with at least 16 or 20 GB of VRAM. For teams that can invest in the infrastructure, it is a path worth exploring, one that decouples your productivity from someone else’s pricing model. Here is a tutorial about my journey implementing custom LLM on Cursor.

Use AI where it multiplies your intelligence. Automate where it would only repeat it.

Build the Machine That Does Not Need the Machine

There is a deeper lesson here, and it goes beyond cost optimization.

If your entire delivery pipeline depends on an external AI service to function, you have a single point of failure priced by someone else. Token prices go up. APIs go down. Models get deprecated. Rate limits tighten. And when any of that happens, your ability to deliver stops with it.

Deterministic automation is yours. You own it. It runs on your terms. It does not get more expensive overnight. And it does not hallucinate.

The architect who invests in automation today is building a shelter for when the token economy changes, and it will change. The one who delegates everything to agents is building on rented land.

Automate with AI. But never depend on AI to execute.

Conclusion

We are at an inflection point. The decisions architects and developers make right now, about what to automate deterministically and what to delegate to AI agents, will define the resilience and economics of their products for years to come.

The question is not whether AI is useful. It is. The question is whether you are building something that survives when the cost of thinking doubles.

So before you spin up another agent, ask yourself: could this be a machine that already knows the answer?

Have you ever heard of Pan de Jamón? I hadn’t—until I met Mike, one of the best developers I ever worked with.

This isn’t a “here’s what bread taught me about life” post. It’s an observation that might bring some light to an AI outlook that can feel pretty dark sometimes.

What made Mike stand out wasn’t only his personality or skillset. It was that he went home and baked Venezuelan Christmas bread.

Ode to the Hobbyist

And it wasn’t only Mike. Most developers I remember, I remember by their hobby.

Just off the top of my mind:

• The genius printing parts on a 3D printer he built himself
• The audiophile building a sound system for a perfect pitch
• The home-automation engineer who wired his house with PLCs
• The architect drilling a water well in his own backyard
• The rotary-engine-obsessed designer with a Mazda RX-7
• The 3D specialist restoring a surf van with his son

None of this is on their LinkedIn profile. None of it pays. And it’s the most interesting thing about them.

I’ve spent a long time in enterprise software, working with developers who write code that runs critical infrastructure.

The pattern is so consistent it stopped being a pattern and started looking like a characteristic: The best developers I’ve worked with don’t stop building when they close the laptop. They go home and make something else—bread, sound, water, vans. They just stop getting paid for it.

What Agents Don’t Have

We live in interesting times. Agents are now colleagues that cooperate in writing our code. And companies are considering, or actively pursuing, what that means for headcount. More and more developers are asking: “Will there be a job for me? How do I compete?”

But here’s what agents don’t do. They don’t drive home and pick up a task that’s not on a kanban board. They don’t lose a Saturday to a bad weld or experiment with different kinds of dough and oven temperatures. They don’t bake a loaf that fails three weekends in a row and quietly absorb the lesson that some processes can’t be hurried, no matter how clever the idea. They don’t ferment, restore, dig, solder, role-play or rebuild.

Agents have no Saturday. They have no irrational, over-obsessed curiosity we call a hobby.

Hobbies are unpressured, unstructured, unscheduled—messy mindbenders. That’s what agents miss. And this unpaid labor is where a lot of real learning happens. The kind that doesn’t show up in the sprint demo, but shows up in great architecture decisions, clever unit tests and surprising solutions.

Don’t Give Up on Your Hobbies

If you’re a developer wondering what to do with the noise about AI replacing you, here’s an honest answer: Look beyond the code. Lean harder into the things you make that nobody pays you for.

Your hobby isn’t a side-quest to the main game of being a developer. It’s not only about balance, self-care or free time. It’s where you keep growing the part of yourself that an agent can’t copy. Where character is formed. Where unconstrained thinking is allowed and you explore solutions only you have to justify.

That wonderful waste of a Saturday is the perspective that breaks through on a mundane Monday morning.

The coffee chat “what did you do over the weekend?” might be the context that wins over the agent whose most coffee-related moment is running a brew command in the terminal.

So bake the bread. Dig the well. Restore the van. Roll the dice.

Keep building without getting paid. That’s the work that keeps you irreplaceable.

For more than 20 years, Progress Telerik has helped developers build better software, faster.

AI hasn’t changed our mission. It’s changed the problems developers need help solving.

That’s why we’re excited to welcome Jeff Fritz back to Progress.

A Familiar Face Returns

If you’ve spent time in the .NET community over the last two decades, chances are you’ve crossed paths with Jeff. Whether through his Twitch channel, conference talks, videos or his work at Microsoft, Jeff has built a reputation for helping developers understand emerging technologies by demystifying complex ideas and making them immediately useful.

But prior to Microsoft, Jeff was part of the Telerik team, where he helped developers embrace modern .NET and web technologies. Jeff’s return to the team isn’t just a sentimental return, it’s also to help Progress as it moves in a new direction .

Like Jeff, for many developers, their journey with Progress Telerik began with our UI components. And we continue to help thousands of organizations build modern .NET and JavaScript web, desktop and mobile applications.

But as software development evolves, so do the challenges developers face. Today, engineering teams aren’t just building applications. They’re integrating AI to produce better experiences at a faster pace than ever.

That’s why we’re expanding the ways we help developers build better software. Alongside our already well-known UI components, we’re investing in tools that help teams build AI-powered applications and agents, accelerate software delivery and confidently observe, manage and govern intelligent systems. As AI reshapes software development, exceptional user experiences remain just as important They’re simply one part of a broader software engineering challenge.

This isn’t a departure from who we are. We are still doing what we’ve always done: giving developers the tools, knowledge and confidence to stay ahead of the next technology curve.

At the heart of every technology shift are the people who help others navigate it.

Throughout his career, Jeff has earned the trust of developers by making complex technology accessible without oversimplifying it. He has an innate ability to help developers understand not just what’s new, but why it matters and how to apply it in the real world.

And that philosophy couldn’t be more aligned with Progress’ own.

“I’ve spent my career helping developers understand what’s changing and how to turn new technology into practical, reliable solutions. Returning to Progress felt natural. This next era of software development demands tools that are thoughtful, durable and built with developers’ real challenges in mind—and I’m excited to help shape them.”

Jeff will be working closely with the community to share, learn, listen and lead. The technologies developers use will continue to evolve. That’s always been true. Our mission remains. We’ll continue helping developers build better software, faster, wherever technology takes us next.

Welcome back, Jeff. Let’s build what’s next.

Emotional intelligence (EI) refers to one’s ability to understand and manage emotions—not just their own, but those of the people around them.

A high emotional intelligence can be incredibly beneficial for web designers. For starters, honing your EI can help you work more effectively with others. Also, it can enable you to create more effective digital user experiences.

In this post, I’m going to share some tips on how designers can improve their work relationships with coworkers, clients and collaborators through emotional intelligence. I’ve also included info on how to use this skill to create more emotionally intelligent designs.

What Does Emotional Intelligence Look Like?

There are two sides to emotional intelligence. First, let’s look at what emotional intelligence looks like when we turn it inward:

Next, let’s look at emotional intelligence turned outward:

Improving Your Work Relationships with Emotional Intelligence

Here are some ways in which you might benefit from utilizing emotional intelligence in the workplace:

• Resolve conflicts speedily and equitably
• Reduce your own stress and prevent burnout
• Contribute to a healthy, supportive work environment
• Improve productivity and collaboration with coworkers
• Improve the client’s experience and build trust and loyalty in the process
• Develop a positive relationship with superiors and pave the way for greater responsibility and job opportunities

Here are some ways you can use emotional intelligence to improve your relationships at work.

Hit the Pause Button Before Reacting

Something happens that makes you want to react.

A client says they don’t like your designs for the second time without giving any constructive feedback. You get scheduled for a third meeting today despite your manager knowing you’re under a time crunch. The account manager didn’t give you all the details about a prospect and so you misspoke during the initial call.

Your body and mind may be screaming at you to react. You feel stuck.

If you react emotionally and right away, there could be negative consequences. But if you don’t do anything about it, you could be stuck with your emotions running high with nowhere for them to go.

To navigate something like this, you need to be able to pause and reflect on the situation objectively. This will give you a chance to slow down your emotions, consider what led to the situation from the other person’s point of view, and then come up with a logical and grounded resolution.

This also can be a valuable learning opportunity.

We all receive criticism at some point in our design careers. We all make mistakes, too. In some cases, our egos want to lash out or reject any responsibility for the situation.

With emotional intelligence, we teach our inner ego not to feel personally attacked or demoralized. Instead, we accept the role we played in the situation and calmly navigate it with the person who has confronted us.

Talk Things Out

I think one of the biggest problems that came about as a result of virtual work is the growing disconnection we feel from others. It’s all too easy to receive an email or request and to misinterpret its intent.

This can lead to:

• Guessing or assuming what the person meant, and then running with your own mistaken conclusions
• Allowing a (possibly perceived) negative experience to fester and then it turning into something bigger than it needed to be
• Feeling frustrated that someone isn’t getting what you’re saying, leaving you to feel as if you have to just do it yourself

In reality, a five-minute phone or Zoom call could have avoided all of this.

While I’m partially laying the blame at the foot of digital communication, poor communication skills in general can create these problems as well.

So, it’s not just important that you’re able to talk things out with others. You need to be able to listen and really hear what they’re saying. This is where social awareness comes into play.

For example, let’s say a junior designer was just hired at your agency. You’ve given them a bunch of tasks to do. You ask them, “Are you good with all this?” And their answer is …

“Yes? Yes. I think so.”

You heard the word “yes,” so that must mean they’re good. Now onto the pile of work waiting for you.

Is that really what they were saying though? While we expect everyone to be responsible for the tasks they assume, this new hire may have just been too nervous to say “no.” Their first “yes” sounded more like a question than an affirmative. And perhaps their body language suggested they were feeling anxious.

So, be careful not to accept certain buzzwords as the truth. Listen and then talk it out if you feel as though there’s a misunderstanding or misalignment between you and someone else.

Be Honest with Yourself and Others

Honesty is a big thing in emotional intelligence. You can see in the example above how dishonesty (no matter how innocent it may seem) can create a lot of problems for a web designer or their team.

When working in collaborative environments—with coworkers or with clients—honesty is critical. And it starts with yourself.

Rather than allowing your ego, fear or other emotions to make decisions for you, have an honest conversation with yourself first.

Let’s say your boss is really pleased with the job you’ve been doing as a senior web designer. They would like you to move into a creative director role by year’s end. The job comes with much longer hours. You’ll also have to complete a few courses between now and then with certifying exams.

You’re excited about the promotion and the increase in pay. In the moment, you want to accept the job, agree to whatever they want and immediately share the news with your partner.

Instead, you ask them for 48 hours to think about it. It’s not that you’re not thrilled about the opportunity, but there are some things to think through.

For starters, can you manage to commit more hours a week? Your partner is already stressed about how much time you work. Plus, the two of you were talking about having kids someday. Would that kind of schedule really be fair to all of you?

What’s more, do you even want to be a creative director? Will you find the work as fulfilling as what you do now? Does money matter more than job satisfaction or fulfillment?

An emotionally intelligent person wouldn’t betray themselves by making a hasty decision or one in which they have doubts. They would consider the matter from all angles, and then be honest about their needs, desires, limitations and so on with others.

Applying Emotional Intelligence to Your Web Design Work

Once you’ve learned how to wield your emotional intelligence on a personal level, you can leverage this skill to create emotionally intelligent digital experiences.

Let’s go back to the idea of emotional intelligence turned outward.

On one side of the coin, there is social awareness. This looks like:

• Recognizing how other people feel
• Empathizing with their situation
• Owning your role in the situation

On the other side is relationship management. This looks like:

• Providing a stable and consistent response
• Adapting your behaviors and reactions to other people and situations
• Being a beacon of responsibility and dependability, so that others feel safe in trusting you

While we can use tools like Google Analytics to tell us what happens on our websites or apps, they don’t help us understand the users’ emotional journey. And without that empathy or understanding, we can’t create digital experiences that are consistent, adaptable, helpful, trustworthy and ultimately satisfying.

To create these types of experiences, you can use:

User Psychology

User psychology can be a useful first step in emotionally intelligent design. For instance, you can use psychology to help you choose colors for your digital experience. It’s a helpful tool, for sure, but it can’t be the only one you use as it really only gives us insights about a generic “audience.”

User Research and Testing

User research methods like surveys, interviews, focus groups and usability tests give us invaluable insights about users. Instead of seeing users as IP addresses that interact with certain pages or screens, they become real people that we’re serving.

With this information, you can go on to develop user personas, empathy maps, user journey maps and content strategies built around your target users’ needs, preferences and challenges.

Feedback Collection

Once your product is live, it’s important to solicit feedback from your users from time to time. The feedback could pertain to their experience with:

• Using the website or app
• Contacting support
• Something they purchased

Feedback isn’t always constructive. Look at any reviews page online and you’ll see people leave one-star reviews with no comments. But if enough people feel passionately enough about an experience, you’ll start getting some really valuable input about what your users like and don’t like.

Iterative Design

In an ideal world, we’d start every web project off with a minimum viable product. This would allow us to deliver just what our users need without wasting too much time on things they might not.

Websites, apps and omnichannel digital experiences can and should continually be improved upon. Whether you’re able to begin all your projects as MVPs or not, iterative design should be part of your process.

When we use critical thinking, empathy and active listening, iterative design goes beyond the superficial. It allows us to really understand our users on an emotional level and to enhance their experiences based on what we learn about them over time.

Wrapping Up

Emotional intelligence is an incredibly valuable soft skill to have as a web designer. Not only can it make things go more smoothly for you at work, it also gives you the ability to design from a more empathetic lens.

Instead of navigating your job as a checklist of things to do, you start to see how your choices and actions affect others—both positively and negatively.

When my daughter spills her drink, she comes to me to tell me it happened.

In that moment, I have two options:

• Act: “Go grab a towel and clean it up.”
• Ask: “How do you think we can fix that?”

The first gets the mess cleaned the fastest. The second takes longer but lets her think.

She grabs paper towels, maybe uses her shirt. She asks for help, or she figures it out herself. Either way, she’s not just following instructions. She’s solving.

It’s a small moment, but it captures something important about how we approach problems.

When we turn a problem into a question, something shifts. Our brains respond differently to questions than to instructions. We get more creative and more motivated. We find solutions we wouldn’t have reached if we’d just executed.

The Push for Execution

In fast-moving product teams, that shift doesn’t always happen naturally. We’re under pressure with tight deadlines, sprints and bugs to fix. There’s a push for execution. The problem gets defined, and a solution shipped. This is efficient but not necessarily effective.

I see it with clients too. There’s a tendency to jump straight to conclusions. Create something, move to the next thing.

We’ve manufactured the wrong sense of progress. We’ve flattened our thinking to activity-based monitoring. We measure work done, not impact made.

And the systems we operate in make us fear being punished for slowing down. But slowing down doesn’t have to be negative. It’s adding depth and establishing foundations to build on.

I’ve seen it happen more than once. A team delivers exactly what was asked. On time and according to spec. But the problem isn’t solved. Not because of poor execution, but because questions were not asked.

The solution was locked in before the problem was understood.

Diverge Before You Converge

This is where design thinking offers something valuable. Divergence and convergence.

Divergence is expanding. You open up the problem space, explore possibilities, challenge assumptions and resist the urge to settle too quickly.

Convergence is getting to the point. You bring constraints back in. Budget, technical feasibility, timeline. And you shape your exploration into something actionable.

Most teams are good at converging. They ship.

But divergence? That takes discipline. It means staying in the question longer than feels comfortable.

How Might We ... ?

A practical tool for divergence is the how might we method. It’s simple. Take any problem and reframe it as a question starting with “how might we.”

The phrasing matters. How might we is optimistic without being naive. It assumes a solution exists but leaves the how open.

Here’s what it looks like in practice.

• “Users keep dropping off at checkout.”
  How might we reduce the friction between cart and payment?

• “Our onboarding takes too long.”
  How might we get new users to their first success faster?

• “Admins can’t manage permissions at scale.”
  How might we make it easier to give multiple people the right access?

Each reframe does the same thing. It takes a complaint or observation and turns it into a space you can explore.

The problem stays the same. But the number of possible solutions grows. That expansion is where the real value lives.

The Question Before the Prompt

This matters even more now that AI has become part of how teams work.

AI is good at execution. Like generating code or drafting copy. It’s a powerful convergence engine. But that’s also the problem.

AI defaults to answers. Give it a problem, it will solve it immediately. It won’t ask if it’s the right problem. It won’t explore alternatives.

That doesn’t keep the frame open. Convergence without divergence is just fast guessing. You end up with the wrong sense of progress again. Shipping solutions to problems nobody questioned.

So the skill that matters most right now is one AI doesn’t default to. Asking more questions. Keeping the frame open longer. Resisting the pull to converge before you’ve explored.

Give AI a vague problem, you get a vague answer. Give it a sharp question, you get a sharper solution.

Takeaways

The question mark might be the most underrated tool in your workflow. Not because questions slow things down. But because they open things up.

Before you assign, build or prompt, ask the question that reframes the problem: How might we?

Because the quality of your answer will never exceed the quality of your question.

Question everything. On purpose.

In my technical accounting course back in the ’90s, there was a class on psychology. Out of everything I learned that semester, one phrase stayed with me until today: “Know thyself,” inscribed at the Temple of Apollo in Delphi and made eternal by Socrates.

Twenty-something years later, with a full career in software engineering behind me, I have realized this is the most underrated skill in our profession. We collect certificates, frameworks, languages and architecture. We stack courses on LinkedIn as if they were trophies. But we rarely stop to debug ourselves.

And what an irony. We, who spend our lives fixing other people’s bugs, are the ones least likely to look at our own.

Photo by Melissa Holowaty on Unsplash

Why This Matters for Those Who Write Code

Socrates also said that “an unexamined life is not worth living.” I would adapt this for our craft: a career without reflection is not worth building.

How many times have you accepted a project knowing it would drain your energy? How many times have you fought over a technical decision that, deep down, was just ego? How many times have you postponed rest because “just one more commit”? These are all symptoms, and symptoms must be treated at the cause, not in the stack trace.

The cause is almost always in a place that hurts to look at. That is why most people do not look.

The Method That Works for Me

There is no shortcut to self-knowledge, but there are tools. Mine are absurdly simple.

1. A Journal Connected to Goals

This is not a teenager’s diary. It is an engineer’s log. I write down epiphanies, decisions, situations that pushed me over the edge, and patterns that keep repeating. Will Durant said, “We are what we repeatedly do,” so I started observing what I was repeating.

2. Reflection Before Sleep

I replay the day in my head and imagine a better version of myself reacting to the same situations. It sounds silly, but it is mental training, just like writing tests for code that does not exist yet. You are programming future behavior.

3. Microsoft TO DO as a Measurement Instrument

I record everything I do during the month and categorize it. The categorized data becomes the input I feed to the AI later (more on that below).

Life Happens in Cycles

One thing I’ve noticed from keeping this habit is that life repeats itself in cycles, and the same lesson keeps coming back until you learn it. Every day, trivial situations (or not) will reappear. If you have already mapped out a better way to react in your head, you will change automatically when they return.

And there are moments when the entire system shifts: a trip, houseguests, a new project. When the ecosystem changes, a window opens to rewrite behaviors. It is like deploying a new version. The environment is already in maintenance mode, so take advantage of it.

I use these windows consciously. But I can only do that because I already know what I want to change. And that knowledge only came from the habit of observing myself.

Where AI Comes In, and Where It Falls Short

Part I: Using the TO DO

I use the TO DO tasks at the end of the month, export them and feed them to AI, asking for an honest analysis: what made me waste time, what I should eliminate and where I am running away from my own goals.

I did this throughout 2025 and into early 2026, and the results scared me, in a good way: too many tasks for a single developer; too many projects in the timeline; and it helped give me focus on the main solutions.

Part II: Using the LLM

This is the part that helped me the most over the past two years. The exercise goes like this.

1. Create a long document with the story of your life. Be detailed. List your traumas, your victories, your shames, your patterns. Be brutally honest.

2. Add a section about what you want to learn in the coming months.

3. Add a section about what you want to achieve in life.

4. Then ask the AI model:

“What did I fail to notice in my own story that is hidden in what I wrote?”

The result may surprise you. It surprised me. AI sees patterns you do not see, because you are inside the pattern.

But, and this “but” is large, AI hallucinates. It will make things up. It will reach wrong conclusions. It will tell you what you want to hear if you give it room. Use the result as a hypothesis, never as a diagnosis. The ideal is still a real therapist.

I use AI as a complementary mirror, and when something really hits me, I take it to someone who knows me, a close friend or a family member, to check it against a human perspective.

AI is a tool. A good and powerful one, but a tool. It does not replace therapy. It does not replace friendship. And it does not replace the courage to look at yourself.

Why It Hurts and Why It Is Worth It

Knowing yourself hurts. You may face things you would rather have forgotten. But those are exactly the things blocking your progress.

Nobody can help you out of your own shell. There is a cruel observation in nature: if you help a chick break its shell, it dies. It did not develop the strength needed for what comes next. Our shell works the same way. The effort itself is the development.

Seek adversity on purpose. Look for challenges that scare you a little. Try to be better than you were yesterday, not better than the developer at the next desk. You are your own obstacle, and nobody is going to fight that fight for you.

Conclusion

This is the path that worked for me. It will not work the same way for you. You need to find your own tools, your own pace, your own style of honesty.

But start. Open a document today, write your story, write what you want from life and what is holding you back. Reread it in a month. Reread it in a year. You will see things that are invisible to you today.

Investing in new frameworks gives you a few months’ advantage. Investing in yourself earns you a lifetime.

A customer threatened to cancel. Full panic. A board meeting to discuss how to retain him, budget approved and allocated to honor his demands. A scrum team started fixing. I flew to the UK to sit with him.

We had redesigned the entire UI. Not a small fix. We completely overhauled the user experience. From a very old tool with toolbars to an application with a strip.

We didn’t just move buttons to ribbons with tabs. We restructured the entire information architecture. Fixed, opinionated workflows that guided users through the critical steps to model complex geological concepts.

He hated it. He demanded a rollback.

I reserved time to interview him. Asked questions. Listened. Tried to sense his reality, his context, where he was coming from. How he was perceiving the changes.

What I discovered changed everything.

He wasn’t even using the latest version. He hadn’t tried the new UI at all. He had simply refused. While we moved on and developed the next generation of our software, he had not. He was still way behind. And somewhere at the back of the queue, feeling ignored and dismissed.

That feeling made him rage. But it also highlighted a bigger problem.

In the room next door, two junior geologists were being trained on the exact same concept. They loved it. The design was exactly what the team needed. What he needed too.

He was desperate for a transformation in his company. A way to step back from his expert role and become a guide for the younger generation. Once I explained the concepts, he understood. He was appreciative of the work. He was on board.

We almost rolled back an expensive, fundamental shift based on an emotional rant from a customer speaking from expired context.

It was never about the concept. It was about misunderstanding context.

The Linearity Trap

A backlog is not a queue. It’s a context-sensitive collection.

Every item in it was written at a specific moment, about a specific reality. That reality changes. The backlog doesn’t update itself.

The linearity trap is treating it like a queue anyway. Adding new requests. Reorganizing. Managing delay. Shipping. Without ever asking: does this still belong in the collection?

The customer had been reporting improvements and bugs for a long time. But we moved on. We shipped. And while we did, he stood still. By the time his feedback reached the top of the queue, the context it was written in had long since changed.

The problem wasn’t that we were behind. We were committing to work that was already outdated.

Delay Is Not the Problem. Decay Is.

A lot of backlog management is really about managing time. Managing delivery. Focused on shipping as much high-quality work as possible by the promised date.

Managing delay is a conscious decision. It’s about choosing when to push something back. That’s prioritization. That’s what I wrote about in the previous article.

But the bigger problem is decay.

Decay is what happens to the work you’re not doing. While you’re waiting, while you’re delaying, what has been written down is eroding. Rusting. Because context expires.

It’s like the best-before date on a package. By the time you grab it from the shelf, you need to check the date before you consume it.

A lot of backlogs are just queues constantly filled with requests, feedback and bug reports. Nobody checks the date. Nobody asks: is this still valid?

I’ve seen old backlog items treated as still true when the context they described no longer existed. They were no longer worth pursuing. The more context you capture when you write them, the easier it is to later assess whether they still fit.

Something can be very old and still be good. But developing the sense to distinguish that is the work. Understanding whether it’s expired or not. Whether it’s still safe to consume.

In the UK, the right response would have been to delay any work on his requests. To first discover whether his feedback was based on expired context. Instead, urgency won. And decay nearly cost us everything.

Urgency vs. Timing

The urgency that came up was really signaling a demand. Someone pushing. Pressure.

And under pressure, you don’t always make the most strategic decisions. The board panicked. Money appeared. Time was freed up. Nobody stopped to check the return on investment, whether it was worth it. It was an emotional response.

That happens. We’re humans. And that emotion is sometimes also why we close amazing deals and do great things for loyal customers. So it wasn’t all wrong. Part of the response was also recognizing the loyalty of a customer who had been with us through harder times.

But urgency gets the attention. It drives the emotion. And what we need underneath it is judgment.

Timing is a readiness signal. It’s not driven by pressure. It’s driven by context.

• Is the customer ready?
• Is the market ready?
• Is the team ready?
• Is the moment alive?

Those are timing questions. Urgency can’t answer them.

Compound vs. Corrosion

We’re always looking for momentum. Shipping as much as we can, as fast as possible, without compromising quality.

But without sensing whether the time is right, we create progress without compounding.

Compounding is making sure what you ship ties into the next thing and builds over time into the desired version of your software aligned with your vision. Creating conditions so that what comes next makes sense.

The opposite is corrosion. Work that sits in the backlog long enough starts to corrode. And when you finally act on it, you might ship something that corrodes the foundation of your software rather than building it. Hurting not just momentum but overall quality.

When we made that big shift to the UI, we should have reassessed the entire backlog. Diagnosed it. Made sure there was no outdated work hiding in the queue because of it.

We didn’t. And a decayed issue almost corroded the core concept.

Context Sensitivity

Why did feedback and previous user requests corrode? Because the timeframe wasn’t short. That concept developed over multiple months. We should have been capturing the context shift and using it as a filter on our backlog to stay ahead of it.

But capturing context is the hard part.

The world moves on. Your market, client and economic reality change constantly. The technical reality shifts the moment you upgrade systems and build with new technologies. The context you’re shipping into is constantly moving.

And on top of that, emotional states. Not everybody handles change well. Not everybody’s personal context is aligned with where you’re going.

You need to develop a sense to see those shifts.

Keep a Human in the Loop

AI is very good at capturing context. Writing it down. Cross-referencing it. Flagging patterns. It can help us see and track everything we can’t manage on our own.

But the moment context is written down, it’s already outdated. And managing that expiration date is a collaborative effort. AI can help cross-check against captured context, flag a customer as a potential churn risk, surface old backlog items that conflict with new ones.

What it can’t do is sit in the room.

What I did with that customer—reserving time, asking questions, listening—that’s a nuance. A human sense that becomes more important as we connect more and more data at greater and greater speed.

AI can read the signal. It can’t always hear what’s between the lines. The emotional rage that looks like a high-priority request but is really a loyalty problem. The developer who goes quiet in sprint planning. The feedback that reads as a bug report but is actually a cry for better onboarding.

That’s not in the data. It’s in the room.

Closure

Timing isn’t about managing deadlines. It’s about reading whether the moment is right. Priority tells you what matters. Timing tells you whether now is the moment to act on it or not at all.

The backlog or data alone won’t tell you that. You need to read the room. Develop that sense. Check the expiration date. Keep humans in the loop for the context AI can’t capture.

We ship when it matters. We shred when it’s expired.

On purpose. By design.

In this post, I want to discuss a real danger we may face with AI agents, drawn from a specific interaction I witnessed on LinkedIn.

Recently, on a post where someone was presenting ideas about “intelligent” AI agents, the author claimed that if a customer fails to pay a SaaS subscription, the system will block access, trigger an automatic charge and apply a late fee, all without any human intervention. This was promoted as something futuristic and advanced.

I saw a disaster waiting to happen, especially considering that the same outcome could be achieved without AI, if that were ever desirable.

What Was Not Considered: The Human Element

There are many situations that can lead to a missed payment. What happens, for example, if the client’s assistant falls ill and cannot process the payment? What if they had a medical emergency and no one took over the task in time? What if the invoice never arrived? What if the client is going through a temporary hardship, but has been a loyal customer for years? Does that count for nothing? Where is the human element in the consumer relationship?

These are not far-fetched hypotheticals. They have happened with my own SaaS customers.

Automation without humanity is oppression at scale.

We could easily implement the AI agent’s suggestion and follow the same path: missed payment, blocked account and a fine applied. But is this the right approach?

My background in neuroscience and communication reshaped how I think about the human side of technology-driven processes. That plus some life experiences lead me to consider the broader context:

• In many jurisdictions, consumer protection laws prohibit unilateral penalties without proper notice. Implementing such a drastic automatic response could have legal implications.
• In society, there is the principle of good faith. Every commercial relationship presumes that both parties act honestly until proven otherwise. This action could have serious consequences for that business relationship and reputation.
• We have to remember to consider the human context. Behind every business and every overdue charge, there are people with stories, setbacks and circumstances that must be considered before any penalty is applied.

What We Should Actually Build

A genuinely intelligent AI agent does not block first and ask questions later. It recognizes patterns. Has this client always paid on time? Then the delay probably has a reason. The system could send an empathetic notification before taking any action. It could offer a courtesy window. It could escalate the issue to a human when the situation is ambiguous. An intelligent agent could prioritize retaining a client, which is often worth far more than punishing a late payment.

For those building AI agents: before you automate punishment, automate empathy. Your system will reflect your values. If you build without considering the person on the other side, you could be constructing a scalable injustice machine, one capable of generating damages that could exceed any original problem the AI was trying to address.

Technology without empathy is not innovation. It is regression with a polished interface.

Conclusion

We are at a moment where the architecture and design decisions we make today will shape how millions of people are treated by systems over which they have no control.

And to help avoid building oppressive and unjust machines, we need to cultivate empathy and uphold our organizations’ principles, with the greater purpose of serving people rather than merely extracting value from them.

Procrastination isn’t usually an issue of laziness or a lack of time-management skills. If we’re talking about chronic procrastination, psychologists suggest it’s an issue having more to do with self-regulation. It goes like this:

• You have an important task to do, be it big or small.
• You know that if you don’t do the task or get it done on time, it’s going to create a problem for you (and probably others as well).
• Yet, you willingly delay the task, knowing full well the consequences.
• The distractions you seek out feel good, but it’s only temporary.

In this post, we’re going to look at some of the reasons why people procrastinate and various tips and tricks you can do to push past it.

Why Do We Procrastinate?

According to Psychology Today:

“Everyone puts things off sometimes, but procrastinators chronically avoid difficult tasks and may deliberately look for distractions. Procrastination tends to reflect a person’s struggles with self-control. For habitual procrastinators, who represent approximately 20 percent of the population, ‘I don’t feel like it’ comes to take precedence over their goals or responsibilities, setting them on a downward spiral of negative emotions that further deters future effort.”

But why exactly do procrastinators not feel like it? There are a number of reasons.

For some, it’s the pressure to be perfect and the fear of failing to live up to that standard that keeps them from getting started.

For others, it’s because they perceive the task as being unenjoyable. So, they seek out something that will bring them joy, even temporarily.

Here are some other reasons why people may procrastinate:

• The task seems too big to handle.
• They see little or no reward in doing it.
• They’re confused about how to do the task.
• They feel overstimulated.
• They feel fatigued.

There are some mental health practitioners who suggest that there’s sometimes something else at play.

Dr. Alice Boyes, for instance, says that “batchers” are often confused for procrastinators. Batchers are people who prefer to complete a set of tasks in a way that maximizes their productivity.

There are seven types. These are the ones most relevant to designers and developers:

1. The time-based batcher waits to do certain tasks at specific times of the day instead of the second they hit their plate.
2. The volume-based batcher waits until they’ve accumulated enough tasks and then cranks them out all at once.
3. The pressure-based batcher waits until they’re closer to the delivery date (just not too close to miss it).
4. The context-based batcher waits until their physical environment is ideal (like the kids going to bed at night).
5. The identity-based batcher waits until a pre-determined time when they work in that capacity (like doing onboarding only on Mondays, wireframes on Tuesday, etc.)

For some procrastinators, it’s not about being irresponsible and delaying a task that needs to get done. It’s that they have a preferred work method that only resembles procrastination.

3 Tricks to Help Prevent Procrastination

Procrastination can feel good in the moment, though many people realize deep down inside the consequences won’t feel very good. Here are some of the consequences that can result from procrastination:

• You wait until the last minute, forcing other critical tasks to go on the backburner.
• You rush through the task, delivering it with errors, bugs, inconsistencies or other quality issues.
• You feel stressed and overwhelmed, which leaves you in a heightened state of aggravation the rest of the day.
• You miss your deadline. Your boss or client is displeased with you, which may keep you from better opportunities or advancements down the road.
• You regularly procrastinate, which inevitably leads to sleepless nights, health issues and burnout.

If you’re worried you’re headed down this path, here are some tricks you can use to stop procrastinating:

1. Use a Task Management Tool

There are a couple of issues that can be resolved by using a project-management tool to schedule your tasks.

Let’s say your boss calls you up and tells you they need a landing page built by Friday for a new Facebook ad campaign. You’ve got it on your mind all week, but you keep dragging your feet. You hate building landing pages and would rather focus on maintaining and updating their website.

There’s a big difference between knowing you have a task to do versus seeing it on a timeline or task list in front of you. That said, you might still feel a sense of pressure whenever you see this looming task.

What may help is having a tool that allows you to create an actionable and fully editable plan for the day, week and month ahead.

My suggestion is to find a scheduler that:

Allows You to Plan Your Days Down to the Hour

Instead of just adding a three-hour task to build the landing page, you can set aside specific hours when you know you will be ready and able to get it done.

Everyone’s most productive hours are different. If you haven’t found yours yet, spend some time looking into it so you can schedule different kinds of tasks when you’re mentally and energetically up to the challenge.

Comes with Drag-and-Drop Capabilities

If you’re not feeling up to a certain task but it’s up next on your schedule, simply drag it to a new time slot where you can reasonably tackle it.

This is why I love calendar-based time management tools. When you can see the whole week or even month ahead, and your deadlines are clearly marked, you can shift things around to suit how you’re feeling in that moment.

Enables You to Build in Free Time or Buffers

If you’re filling your schedule to the brim every day with no wiggle room, it’s going to make any level of procrastination worse. So, give yourself some breathing room.

For instance, I give myself a two-hour break in the middle of every work day. I don’t have to use it all. But just having it on the calendar gives me the grace to work when I’m up to the task instead of wasting my time on social media, Reddit, etc.

Allows You to Check Off Tasks as You Finish Them

The physical (or digital) act of checking an item off a task list releases a hit of dopamine.

One of the reasons why procrastinators seek out distractions is to activate their pleasure center. By setting up your task manager to create a similar sensation (and one that comes with rewards in the end instead of consequences), it may become addictive in a positive way.

2. Make the Task Smaller

A lot of times, it’s the size of the task that intimidates people and leads them to procrastinate. For example, let’s say you’re building a design system for a new app you’re working on. You’re dreading the task because of how long or complex it’s been in the past. You have a six-hour block on your calendar to get it done and you keep pushing it back.

10:00 a.m. - 4:00 p.m.: CREATE DESIGN SYSTEM FOR CLIENT A

So, how about this?

Look at your deadline. Do you have some time before it needs to be done? Great. Then rather than set aside six hours (or however long you think it’ll take), create a 15-minute task for your next free moment:

10:00 a.m. - 10:15 a.m.: Duplicate design system for Client X and save to Client A folder

Create a copy of the design system from the previous job, and save it in the project folder you’re currently working on. While you’re in there, update the basic client details so you don’t have to worry about it later.

Not ready to do more right now? That’s fine. Add a new 30-minute task to your schedule when you have the time, energy or focus:

3:30 p.m. - 4:00 p.m.: Swap out colors in design system for Client A’s

You can do this with the remainder of the steps required to finish the overarching task.

For a lot of procrastinators, this approach can make difficult or time-consuming tasks feel more manageable. So long as you keep an eye on that deadline, you can make these small, incremental steps toward completing the whole task over time instead of all at once.

3. Cut Down on Your Decision-making

There’s a UX Law called Choice Overload. It states that:

“Overchoice or choice overload is the paradoxical phenomenon that choosing between a large variety of options can be detrimental to decision making processes.”

We see this in UX design all the time. When you give users far too many choices to make or too many options to choose from, some of them just decide it’s best to make no choice at all.

How does this play into procrastination?

Let’s say you have four web development projects you’re working on this month. They’re all at varying stages. You look at the calendar for today and see the following tasks:

• 1-hour kickoff call with Client B
• 30-minute weekly check-in with team
• 3 separate 30-minute user testing sessions to moderate for Client A
• 2 hours of market research for Client C
• 3 hours of user persona development for Client D
• 32 unread emails
• 11 unread Slack messages

The first three you have to do. The problem is, they’re scattered haphazardly throughout the day. So, trying to get the market research and user persona work done in one single stretch is going to be hard. You tell yourself you’d much rather do that work than check your messages, but you just can’t get started.

Those unread messages are weighing on you. You know that checking them would be the quickest thing to do and it wouldn’t be a big deal if they get disrupted by the calls or user testing sessions. However, you know they might add more work (and possibly stress) to your plate.

So, what do you do?

The more brainpower you expend on “What should I do next?” or “How do I avoid this task I’m dreading,” the more energy you’re sapping away from work you need to do. The best thing is to reduce the number of decisions you have to make.

When it comes to managing tasks, you can do this by having dedicated hours for when you do certain things, like the time-based batcher method mentioned above.

For example, you might hold space on your calendar every day from 8:00 to 8:30 a.m. and again from 4:30 to 5:00 p.m. to check messages. By doing this, the 32 emails and 11 Slack messages no longer become something you have to contend with when figuring out what to do next.

Another thing you could do is set rules for when you can be scheduled and for what kinds of tasks. For instance, you could have dedicated days for meetings and calls. What’s more, you could restrict those calls to a set timeframe, like between 9:00 a.m. and 12:00 p.m. This way, your calls wouldn’t be spread out all over the place, making it challenging to get larger tasks done.

Wrapping Up

We procrastinate because we anticipate some sort of discomfort or displeasure at performing a task. It could be that we believe the task will be too hard, that we won’t be able to do a good job or that it’ll bore our brains out.

Some people turn toward distractions that temporarily pause those feelings that have arisen. The only problem is that the joy and relief that come from those distractions are not long-lasting. What’s more, procrastination can exacerbate the consequences of not doing the task when you had initially planned to.

Rather than get stuck with this kind of habit whenever you feel the urge to not do something, train yourself to develop new habits. Schedule all your tasks, but allow yourself the flexibility to move things around as needed. Break up bigger tasks into smaller steps to reduce overwhelm. And come up with rules so you’re not having to expend so much mental energy on what to work on and when.

It depends.

If you ever ask a design question, most likely this is the answer. It depends.

It’s true. Everything depends on something else. There’s no black or white, right or wrong answer, because it always depends. This is the context you’d need to understand. How it’s related.

This applies to your backlog as well. In previous articles, we covered priority and timing. When does something deserve attention, and in what order do you pick up work. And even when you know what to pick up, when matters.

So let’s say you know what work to pick up and when to pick it up, the question still worth asking is: what does it depend on, and is anything else depending on it?

We call this “dependency management.” I think that means more than a dependency graph. It’s about relationships and context.

The Regulatory Reflex

We often manage dependencies well as part of backlog management to mitigate or address risk. And there’s a reflex, a regulatory reflex, that makes us lean toward risk avoidance.

A dependency gets seen or projected as a negative thing. That risk, the thinking goes, can then be mitigated by reducing dependencies.

I’ve seen this a lot in product development. “Dependency management” became a synonym for reducing dependencies. Avoid the vendor. Build it yourself. Own the code, own the outcome. Right?

It sounds strategic. But it rests on the wrong definition of independence.

Does True Independence Actually Exist?

Here’s the question to ask yourself: Does true independence actually exist?

The word independence literally means “not to hang from.”

In (not) + pendere (to hang).

The whole concept is built on negation.

But you always depend on something. A framework, team, budget or a market. Even the time you have in a day.

The question isn’t whether you depend. It’s what you depend on and whether that dependency works.

Fortunately, there’s another way to read that same prefix.

The in- in independence has another root. The one in include, inject, integrate, insight. In as into, within, part of. Not negation. Integration.

Read that way, independence doesn’t mean “not hanging from.” It means “hanging in.” Being part of something. Integrated into a larger system. Intentional.

That’s a very different idea than avoidance.

You’re not running from dependencies. You’re choosing which ones to integrate into. Seeing them clearly. Selecting them deliberately. Keeping the freedom to shift them when the system needs to evolve.

Not the absence of dependencies. The presence of deliberate ones.

A purposeful assembly of parts. That’s what we should mean when we say “independent.”

A New Definition: Clarity, Choice, Change

True independence is about intentional integration, based on three requirements:

• Clarity: You can see what you depend on.
• Choice: You can select your dependencies deliberately.
• Change: You can shift them when you need to adapt to reality.

Dependencies you see clearly, chose on purpose and can shift aren’t risks. They’re the assembly.

The risky ones are those you can’t see, didn’t choose and can’t change. And those are often the ones created by chasing the wrong definition of independence in the first place.

The Pain of the Wrong Definition

I worked on an edge connectivity ecosystem for remotely operating oil rigs. The goal was to standardize how software ran at the edge. Authentication, data access, data streaming, etc. All the foundational components every new project needed.

We built those components once, so other software teams wouldn’t have to rebuild them every time.

It was a strategic bet. I did a lot of the narrative work, high-stakes pitches, executive alignment, the whole thing. The argument was simple: consolidating common parts saves money, reduces waste and lets the company move faster.

The numbers worked. But the adoption didn’t.

A lot of product teams resisted. Some flat-out refused. The cost-saving argument was easily offset by something they felt more acutely: the fear that being tied to a centralized platform would hold them back later. That when they needed to solve a new problem or make a different strategic choice, this dependency would be in the way.

They heard the pitch as: Give up your freedom to build, and we’ll give you efficiency.

And under the old definition of independence (the negation one), they were right to resist. We were asking them to depend on something they didn’t fully control.

But that’s not what was actually happening.

We weren’t asking them to give up independence. We were asking them to redefine it. To stop measuring freedom by what they built themselves, and start measuring it by what they could deliberately depend on. Clearly, on purpose, with the ability to change.

The pain wasn’t the dependency. The pain was the wrong definition.

What the Ecosystem Actually Offered

Before the platform, every team built authentication, data access and streaming from scratch. They depended on their own budget, their own developers, their own expertise. Their speed, their skill and their security were limited by what each individual team could pull off.

The result was scattered software. Reinventing the wheel. From a company perspective, it was waste: the same work, done badly, in parallel.

What the ecosystem offered wasn’t fewer dependencies. It was better ones.

A centralized team with deep expertise. A dependency the company could see, manage and improve. The freedom to shift the underlying technology when something better came along, because the contract was clear and the boundaries were defined.

The product teams’ dependencies didn’t shrink. They grew. But they became something the company could actually manage.

A purposeful assembly, with each part chosen.

The Same Pattern, Smaller Scale

The same pattern showed up in our design system work.

Teams had been forking and falling out of sync, maintaining custom code originally built by an external agency. When the agency engagement ended, we kept the code, but not the expertise. Internal teams were on the hook for something they hadn’t built.

The fix was the same shape as the platform shift: move from custom in-house code to a well-documented third-party framework. We migrated to Progress Kendo UI. The license fee was new but visible. The hidden internal cost, buried in cross-charges and undocumented maintenance, went away.

We even ran a hybrid model. Kendo UI for most components. Different libraries for charting and mapping if Kendo UI wasn’t the best fit. More dependencies, technically. But each one chosen on purpose. Each one we could see and could change if needed.

Different definition.

What Independence Actually Looks Like

The question was never how do I become independent? It’s what am I depending on, and does it work?

Independence isn’t escape from dependence. It’s intentional integration. Clear. Chosen. Changeable.

A purposeful assembly. That’s what independent should mean. On purpose. By design.

A few weeks ago, the Progress team headed to Amsterdam for React Summit and JSNation: two of the back-to-back biggest events on the JavaScript calendar.

Between the packed schedule, booth conversations, social events and time hanging out with a few hundred of your closest developer friends, it was a seriously week. Not to mention, our team finally got to spend some time together in-person—something that doesn’t happen very often when you’re scattered across the globe! Although we all left feeling exhausted (and at least in my case, wildly jet-lagged), it was absolutely worth the trip.

Our own Kiril Peyanski took the React Summit stage to deliver a talk on generative frontend, exploring a new paradigm where LLMs generate the logic that maps data to UI using React Server Components and Server Functions to make interfaces that adapt to the user. And when I tell you the room was packed, I mean literally standing room only and overflowing out the door!

As part of the conference, we also hosted a hackathon in partnership with GitNation, challenging attendees to build something that makes tech conferences better. We left the specifics up to our hackers. It could mean better for attendees, better for speakers, better for organizers or something else entirely. We wanted to see how creative folks would get, and the response blew us away. The hackathon lasted just 48 hours, and we had over 30 finished projects!

After judging (which, let me tell you, was a real challenge), three projects stood out from the crowd:

Our grand prize winners, HALLWAY: The team behind HALLWAY built a mobile-first app that turns the chaos of a conference day into a personalized, connected flow. Answer a few quick questions, and it builds your schedule, fills your free gaps with curated intros to the right people, and places you in a small group for the evening.

Our first runner-up, Conf Pilot: Conf Pilot is an MCP server that brings live conference schedules directly into AI chat. Ask "what’s next?" and instead of a wall of text, you get a fully interactive, themed widget with track filters, live countdown timers and calendar links—all without leaving your AI assistant. One of the first projects to use the new MCP Apps structured content pattern, and a seriously impressive build for a one-person submission!

Our second runner-up, Stuck Stack: Stuck Stack turns the conference into a live help marketplace. Post what you’re blocked on, find someone nearby who can help you in five minutes, and watch blockers move across a live board from Open → Matched → Solved. Organizers get a real-time dashboard that can even detect when enough attendees are stuck on the same thing and suggest a pop-up help clinic on the spot. Clever, useful and beautifully designed.

However, we couldn’t give prizes to everyone—as much as we wished we could! When I tell you the judging was a challenge, it’s because we had other submissions like these that were so, so impressive. While these unfortunately didn’t end up placing, we do want to make sure they get their time in the sun as well, so you can also appreciate their incredible work!

The Hallway took a new swing at the age-old problem of networking. Your AI agent walks into the conference before you do, negotiates with other attendees’ agents to find the right matches and only reveals identities once both humans consent.

Unison tackled something nobody else touched—language barriers. It dubs conference talks in real-time, letting speakers present in one language while every attendee hears it in their own, with no headsets and about a three-second lag. Two-way, too: attendees can ask questions in their language and the speaker receives them in theirs.

CrowdShift flipped the speaker experience on its head. Speakers normally prepare blind, with no idea who’s actually in the room. CrowdShift pulls registration data and builds a continuously updated audience brief, so a speaker can see that their crowd shifted from 65% senior to 55% junior and adapt their talk in real time.

ConferenceCast treated a multi-track conference like a TV broadcast: every room is a channel, and you get a personalized program guide with AI match scores, live session cards, countdown timers and a control-room dashboard for organizers to track what’s working in real time.

FireRaven Conference Hub went after a bigger problem: conference discovery is basically guesswork. Their platform gives speakers portable reputation profiles and lets attendees rate events across meaningful dimensions—expertise, clarity, practical impact and energy.

Nexo kept it focused: tell it your role, goals and interests, and it builds you a focused conference plan with a clear explanation for every recommendation. Sometimes, the best solutions are the simple ones.

Stage Deployer changes how you give talks. It lets speakers create small audience apps from a simple text prompt. Just type an idea, wait about two minutes, then share a QR code for the audience to scan. The interaction results appear live on the big screen as charts, rankings or word clouds.

We highly encourage you to check out all the submissions in the project gallery and see the incredible variety of things people built with Telerik and Kendo UI components from Progress Software.

Amsterdam delivered on all fronts: the venue was great, the crowd was friendly and the whole experience reminded us just how great it is to be able to spend time together with a bunch of folks all excited to geek out about the same stuff.

Huge congrats to all three of our hackathon winning teams, and a massive well done to every single person who submitted. More than 30 projects in a couple of days is no joke! We had a fantastic time, and we’re already looking forward to the next one.

Ready to build your next React app?

Explore KendoReact

You know the feeling. Another feature. Another bug. Another stakeholder request that can’t wait. You fight the fire.

And somewhere at the end of the week, you look at your changelog and realize you’re no closer to where you wanted to be.

That feeling is the ER mindset. And if you’re building software, managing a product or owning a business, there’s a good chance it’s running your backlog.

The ER Is Not the Problem

The emergency room excels at prioritization under pressure. Triage nurses make life-or-death decisions in under 60 seconds. They sort by urgency and severity. They don’t treat the loudest patient first. They treat the one who needs it most.

But here’s what often gets missed: the ER is part of a bigger system.

A hospital doesn’t only treat emergencies. It prevents emergencies before they happen and treats patients who need real care. The ER is one room in a much larger building. A dedicated room with a purpose.

The problem isn’t the ER. The problem is when your entire backlog becomes one.

When everything is urgent, nothing is. You respond. And respond. And respond. And the work that deserves real attention—the strategic work, the preventive work, the work that would stop the emergencies from happening in the first place—never gets done.

What the ER Gets Wrong

The ER triages everyone who walks through the door. That’s by design. It has to.

But your backlog shouldn’t.

Most prioritization frameworks—like the Eisenhower Matrix, MoSCoW and RICE—jump straight to scoring. Urgency. Importance. Effort. Impact. They assume that everything entering the system deserves to be evaluated.

That is an expensive assumption. Because most backlogs are approached from an operational perspective. What’s urgent. What’s important. What’s next. Useful, but it skips the bigger picture. The vision, the version you’re building toward.

And that’s exactly what you need to ask: Should this be in the system at all?

The 3P Triage Framework

This is what I call the 3P Triage Framework. Purpose. People. Profit. Three-stage triage. Each one a filter before the next.

Purpose

Purpose is the viability check.

“On purpose” means the work is intentionally aligned with where you’re going. Not just relevant. Directional. Walking the line toward what you’re actually building.

“By design” means you have a clear version defined that you’re building today. Not someday. Not “we could.” Clarity on what version of the vision you are releasing next. One check. One big question:

• Is it on purpose and by design? Yes / No

If the answer is no, the item doesn’t fit. It gets filtered out before it’s ever scored. You assign it to a future version or remove it altogether.

This is an important step to add in backlog triage and the one often skipped. Without it, you triage everything. And when you triage everything, you’re back in the ER.

People

People is the desirability check. This is where urgency and importance come in.

How critical is this right now? What’s the impact if we don’t act? Who needs it? What does it unlock or block?

This is the proven system. The meat of prioritization. Eisenhower had the right instinct here. The problem wasn’t the framework. It was applying it without context.

When every item in your backlog has already passed a purpose check, urgency and impact become meaningful signals. When they haven’t, everything feels urgent.

Score both on a simple scale:

• Urgency: Low / Medium / High / Critical
• Importance: Low / Medium / High / Critical

Profit

Profit is the feasibility check. The final lens of reality.

Can we actually do this? What’s the effort? What’s the risk? What might we break, slow down or delay by taking this on? What do we gain? What’s the return on investment?

Not just “can we build it?” but “can we afford to build it right now, given everything else?” And is it profitable to do so?

Size up all three:

• Effort: S / M / L / XL
• Risk: S / M / L / XL
• Revenue: S / M / L / XL

I’ve seen teams spend a sprint fixing a bug that affected three users, while a performance issue slowing down everyone quietly compounded in the background. I’ve seen initiatives invented to add capabilities to a part of the product our vision was trying to make obsolete in the industry.

Sometimes the most strategic move is removing something entirely. Maximize work not done.

With this 3P Triage Framework, you now know the value, the priority of a task. But when do you work on it?

Priority Is Not Order

This is the distinction that changes how you use all of this.

• Priority is an understanding of value. It tells you what matters most.
• Order is a commitment to act. It tells you what’s next.

They are not the same thing.

A low-priority item can hold a high order position, because of timing, dependencies or readiness. A high-priority item might sit lower in the order because the conditions aren’t right yet. Confusing priority with order is where backlogs fail.

When they’re treated as the same thing, urgency drives execution. Again. Technical debt never gets solved. Prevention never gets resourced. You’re back building a response system instead of a product.

And the emergencies keep coming. Because nothing is preventing them.

Closure

The ER isn’t the problem. The ER mindset is. The emergency room responds to urgency. Your backlog shouldn’t.

Real triage starts with a check: Is this aligned with our purpose? Does it fit the design we have? Only then does urgency and impact matter. Only then does feasibility make it worth it.

That’s the difference between a team that responds and a team that builds. On purpose. By design.

Every time I see it, it catches my eye. As a designer, I can’t help but notice.

I don’t know if you see this where you’re from, but here, I see pieces of paper taped to doors: “Pull, don’t push.” Or a coffee machine with a post-it next to the button: “Press this first.”

These additions are almost never part of the original design. They appear later as a fix.

Whenever you see extra instructions layered on top of something, it’s usually a sign of poor design. The object didn’t make its purpose clear enough on its own.

In design, we call this affordance.

What Affordance Really Means

Affordance is about perceived purpose. It’s the relationship between an object and the actions it suggests. A handle suggests pulling. A flat plate suggests pushing.

My coffee machine, a Sage, has buttons that light up with LEDs. They highlight which button to press next. Love it! Even my 2-year-old can operate it.

Good affordance doesn’t need explanation. You don’t think. You act.

That’s why well-designed objects don’t rely on manuals. The design itself guides you toward the intended action.

When affordance is clear, usage feels natural. When it isn’t, we compensate with signs, instructions, warnings and rules.

And that’s where things get interesting.

When Design Needs a Manual

The moment you need to explain how something should be used, the design has already failed.

We often accept this in physical spaces and in software too. We’ve learned to live with bad doors, confusing elevators and interfaces full of hints and labels.

But we do something similar with people.

In Dutch, there’s a saying that maybe doesn’t translate perfectly, but the meaning is clear: “That person comes with a manual.” We use it when someone is hard to understand. Hard to work with. You need instructions.

Think about that for a moment. We talk about humans as if they were poorly designed objects that need instructions to function properly.

Affordance Outside of Design

This is where the principle starts to matter beyond design.

Affordance isn’t just about usability. It’s about recognition and understanding. About purpose. It’s about whether others can see what you’re capable of without needing a long explanation.

In work, careers and organizations, we often rely on uniformity to create clarity. Standard resumes, roles and career ladders.

Uniformity creates predictability. But it doesn’t create affordance.

When everyone looks the same on paper, it becomes harder to see what makes someone valuable. The potential of people is unleveraged.

Standing Out on Purpose

Good design sometimes requires contrast. Something has to stand out for affordance to work.

The same applies to people.

If you blend in too well, your affordance disappears. Others can’t see what you’re uniquely good at. Not because you lack value, but because the design doesn’t surface it.

Standing out isn’t about being loud. It’s about being intentional. I often describe this as standing out on purpose.

Not for attention. But for clarity.

When I work with people on career design, the core challenge is rarely skill. It’s visibility. Their purpose isn’t expressed in a way others can recognize.

So we redesign how their value is presented. Not by changing who they are, but by emphasizing purpose. Increase the affordance.

Affordance Is Contextual

Affordance always depends on context.

A door handle that works in one environment might confuse you in another. The same is true for people.

“Just be yourself” sounds good, but it ignores the environment you’re operating in. Affordance isn’t about self-expression in isolation. It’s about how your purpose is perceived within context.

Good design finds that symbiosis. Clear, functional and purposeful.

Takeaways

Affordance teaches us something simple but powerful: If people constantly need instructions to understand you, it’s worth asking whether your affordance is clear.

Not to conform yourself. But to present your value.

Good design reduces the need for explanation. In objects. In interfaces. And in life.

Stand out on purpose.

Read next: Design Principles Unpacked, No. 4: Balance