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

Building accessible components is one of those things we know we should do, but often skip because it feels overwhelming. We need to read about accessibility tips and tricks and a lot of documentation.

You start with a simple dropdown menu, knowing you need to handle keyboard navigation, ARIA attributes, focus management and screen reader support. Before you know it, your “simple” component has 200 lines of accessibility code you’re not even sure is correct. (Unless you’re using the Progress Kendo UI for Angular library, which has accessibility baked in for you. )

What if I told you there’s a way to get the accessibility magic you need, regardless of component library, with full control over your styling with the magic of Angular Aria?

But what is Angular Aria? Let’s make a small intro.

What Is Angular Aria?

Think of Angular Aria as a collection of accessibility superpowers for your components, but instead of manually implementing keyboard navigation, ARIA attributes and focus management, you import a directive, add it to your HTML and, boom, your component is accessible.

The Angular team built these directives following the W3C Accessibility Guidelines, so you don’t have to become an accessibility expert to build compliant components.

Hold On, What About Angular Material?

Great question! If you’ve been using Angular for a while, you’re probably thinking: “We already have Angular Material. Why do we need another library?”

Here are the key differences:

Angular Material gives you complete, prestyled components. They look great out of the box, but they come with Material Design opinions baked in. If you want a button that doesn’t look like a Material button, you’re going to fight the framework.

Angular Aria gives you headless directives—just the accessibility logic, zero styling. You get all the keyboard navigation, ARIA attributes and screen reader support, but you control every pixel of how it looks.

Think of it this way:

• Angular Material: It is plug and play, looks good, works immediately, but everyone has the same result. If you were building a physical doorway to your business, it would look like all other businesses, just with your business name on the sign.
• Angular Aria: This tool is more like the ramp to your front door, enabling anyone to access the business entrance, while allowing you to choose the awning, the window display and the door color.

So when should you use each one? We’ll dive deeper into that later in the article, but here’s the quick answer:

• Use Angular Material when you need to ship fast and Material Design works for you.
• Use Angular Aria when you have custom design requirements and need full control.

Remember, accessibility isn’t optional anymore. It’s a legal requirement in many countries, and, more importantly, it’s the right thing to do.

But implementing accessibility correctly is hard. You need to know:

• Which ARIA attributes to use (and when)
• How keyboard navigation should work for each pattern
• How to manage focus properly
• How screen readers interpret your markup

Angular Aria handles this complexity for you. You focus on the HTML structure, CSS styling and business logic, and Angular Aria takes care of accessibility.

But, as always, the best way to learn is by building something. Let’s do it!

Set Up the Project

First, create a new Angular application. In your terminal, run the following command (be sure to have Node.js installed).

npx @angular/cli@latest new angular-aria-demo

When CLI prompts stylesheet format, pick CSS.

  - **Which stylesheet format would you like to use?** → CSS

Now, navigate to your project and add Angular Aria:

cd angular-aria-demo
npm install @angular/aria

That’s it. We now have a fresh Angular project with Angular Aria installed. Let’s build something accessible!

Building an Accessible Toolbar

Let’s build a text formatting toolbar, the kind you see in rich text editors. This is a perfect example because it looks simple but has surprising accessibility complexity.

Using the CLI, generate a new component editor-toolbar:

ng generate c components/editor-toolbar

Perfect! Open the component with your editor, and import Toolbar, ToolbarWidget and ToolbarWidgetGroup directives provided by @angular/aria/toolbar.

  import { Component } from '@angular/core';
  import { Toolbar, ToolbarWidget, ToolbarWidgetGroup } from '@angular/aria/toolbar';
  
  @Component({
    selector: 'app-editor-toolbar',
    templateUrl: './editor-toolbar.component.html',
    styleUrl: './editor-toolbar.component.css',
    imports: [Toolbar, ToolbarWidget, ToolbarWidgetGroup],
  })
  export class EditorToolbarComponent {}

Now it’s time to build the HTML structure. We create a div container with the directive [ngToolbar], which works as the main container. We also need ToolbarWidget to use with individual buttons and ToolbarWidgetGroup for groups of related buttons.

In the following HTML, we use every directive with divs and button elements. Copy it and paste into the editor-toolbar.html.

  <div ngToolbar aria-label="Text Formatting Tools">
  <div class="group">
   <button ngToolbarWidget
           value="undo"
           type="button"
           aria-label="undo">
     Undo
   </button>
   <button ngToolbarWidget
           value="redo"
           type="button"
           aria-label="redo">
     Redo
   </button>
 </div>

 <div class="separator" role="separator"></div>

 <!-- Text formatting group -->
 <div class="group">
   <button ngToolbarWidget
           value="bold"
           type="button"
           aria-label="bold"
           #bold="ngToolbarWidget"
           [aria-pressed]="bold.selected()">
     Bold
   </button>
   <button ngToolbarWidget
           value="italic"
           type="button"
           aria-label="italic"
           #italic="ngToolbarWidget"
           [aria-pressed]="italic.selected()">
     Italic
   </button>
 </div>

 <div class="separator" role="separator"></div>

 <!-- Alignment group (radio buttons) -->
 <div ngToolbarWidgetGroup
      role="radiogroup"
      class="group"
      aria-label="Text alignment options">
   <button ngToolbarWidget
           role="radio"
           type="button"
           value="align left"
           aria-label="align left"
           #leftAlign="ngToolbarWidget"
           [aria-checked]="leftAlign.selected()">
     Left
   </button>
   <button ngToolbarWidget
           role="radio"
           type="button"
           value="align center"
           aria-label="align center"
           #centerAlign="ngToolbarWidget"
           [aria-checked]="centerAlign.selected()">
     Center
   </button>
   <button ngToolbarWidget
           role="radio"
           type="button"
           value="align right"
           aria-label="align right"
           #rightAlign="ngToolbarWidget"
           [aria-checked]="rightAlign.selected()">
     Right
   </button>
 </div>
</div>

The final step is adding some CSS styles to make it look nice. Open the editor-toolbar.css and paste the following style:

  [ngToolbar] {
 display: flex;
 gap: 8px;
 padding: 8px;
 background: #f5f5f5;
 border-radius: 4px;
}

.group {
 display: flex;
 gap: 4px;
}

.separator {
 width: 1px;
 background: #ddd;
}

button {
 padding: 8px 12px;
 border: 1px solid #ddd;
 background: white;
 border-radius: 4px;
 cursor: pointer;
}

button[aria-pressed="true"],
button[aria-checked="true"] {
 background: #007acc;
 color: white;
}

Perfect, we just added HTML, CSS and Angular Aria directives. To test it, open the app.html and add <app-editor-toolbar></app-editor-toolbar>, save changes and run your app.

ng serve
Initial chunk files | Names         | Raw size
main.js             | main          | 10.50 kB | 
styles.css          | styles        | 95 bytes | 

                    | Initial total | 10.59 kB

Application bundle generation complete. [0.641 seconds] - 2026-01-25T10:16:33.843Z

Watch mode enabled. Watching for file changes...
NOTE: Raw file sizes do not reflect development server per-request transformations.
  ➜  Local:   http://localhost:4200/
  ➜  press h + enter to show help

Try to use your toolbar with your keyboard. You’ll find it works, and we didn’t have to write any code for keyboard navigation logic (like: Arrow keys, Home, End), focus management, ARIA role attributes, screen reader announcements or selection state management. All of that complexity? Gone.

The ngToolbar, ngToolbarWidget and ngToolbarWidgetGroup directives handle all of that automatically.

We now have a fully accessible toolbar that works with keyboard navigation and screen readers, and we only wrote the HTML structure and CSS.

Angular Aria provides directives for the most common interactive patterns, we can get components for search and selection (like Autocomplete, Listbox and Select), navigation and actions (Menu, Menubar and Toolbar like we just built), and content organization (Accordion, Tabs, Tree and Grid). Every directive comes with complete documentation, working examples and API references. You can see the full list of available components in the official Angular Aria documentation.

But I’m a Fan of Angular Material

Yes, I understand Angular Material has a long relationship with Angular devs. You can continue using Angular Material when you:

1. Need to ship fast – You’re building an MVP or internal tool and don’t want to spend time on custom styling.
2. Like Material Design – You’re OK with the Google Material Design aesthetic.
3. Have limited design resources – Your team doesn’t have dedicated designers.

Remember, Angular Material is amazing, but it comes with opinions about how things should look.

If you try to heavily customize Material components, you’ll spend more time fighting the framework than building features. I’ve been there—overriding Material styles with ::ng-deep and !important until the CSS becomes unmaintainable.

And don’t even get me started on theming. Creating a custom theme for Angular Material is… let’s just say “special.” It’s doable, but it’s tricky and requires deep knowledge of Sass and Material’s theming system. (If you’re curious about the complexity, I wrote about it in Theme UI Frameworks in Angular: Part 2 - Custom Theme for Angular Material.)

Angular Aria solves this by giving you zero styles. You start with a blank canvas and build exactly what you need.

Remember for simple cases, native elements are already accessible when you use <button> for buttons, <input type="radio"> for radio buttons or <select> for simple dropdowns. But Angular Aria gives you a third option: headless accessible components that you can style however you want, we can meet accessibility requirements, maintain full design control and avoid reinventing the wheel.

Recap

We learned that accessibility doesn’t have to be overwhelming. Angular Aria gives you production-ready, WCAG-compliant directives that handle the complex parts.

We provide the HTML structure and CSS and Angular Aria provides the accessibility without pain!

But What About Kendo UI?

Maybe you want to ship faster (really fast) and have complex scenarios with datalist, charts, schedulers and complex UI patterns. If you read this article and are thinking: “This is great, but I still have to write all the HTML and CSS myself. Why not just use a complete component library?” you’re asking the right question.

Here’s when Progress Kendo UI for Angular makes more sense than Angular Aria or Angular Material:

Use Kendo UI when you want:

1. Everything out of the box – Prebuilt components with professional styling, themes and accessibility already done
2. Advanced features included – Things like data grids with sorting/filtering, charts, schedulers and complex UI patterns
3. Consistent design system – A cohesive look across all components without writing custom CSS
4. Enterprise-grade support – Professional support, regular updates and guaranteed compatibility
5. Speed PLUS customization – You need to ship fast and need options to customize (you’ll have five fully built theme options plus the ability to tweak those or create your own theme)

There’s no “wrong” choice—just different tools for different jobs.

If you’re building internal tools or you like the Kendo UI design system, Kendo UI saves you weeks of work, and, honestly? I can build complex stuff (data grids, schedulers, charts) in minutes, making Kendo UI the right answer for me.

Plus, you can use the Kendo UI for Angular AI Coding Assistant, an MCP server that automatically scaffolds components for AI agents. Instead of manually writing Kendo UI components, your AI assistant can do it for you.

Want to learn more? Check out my article: Angular and Kendo UI MCP: Making Agents Work for You

• Source code
• Angular Aria Documentation

In this post, I share my perspective from 30 years of building systems, from MRP II in 1994 to AI-powered ecommerce solutions today. I’ve learned lessons that are worth their weight in gold. I see too many students focusing on things that don’t generate the expected impact, so I’ll be direct about what really matters.

Fundamentals Are Your Superpower

Frameworks come and go. I’ve seen so many emerge and disappear that I’ve lost count. But do you know what remains relevant? Understanding data structures, algorithms and the fundamental principles of programming.

When I started my programming career, it was with Clipper. Then VB6, JavaScript and finally C#. Each transition became easier because the fundamentals were solid. Today, I see people jumping straight into React or Angular without truly understanding JavaScript. When the framework changes (and it will change), those people get lost.

Before diving into the next trendy framework, make sure you understand data structures, algorithmic complexity, design patterns and how your language actually works. This will save you when you need to decode that impossible bug at 2 a.m.

Portfolio over Certificates

In 1997, I started building Advocati.NET, a complete management system for law firms with integrated CRM that evolved from VB6/Access to C#/ASP.NET/SQL Server. That project opened more doors for me than any certificate ever could.

Build real things. It doesn’t need to be revolutionary. A well-made CRUD with tests, CI/CD and clean code already puts you ahead of 80% of candidates. Even better: Solve a real problem, even if it’s small.

My advice: Take a problem that you or someone close to you has. Build an end-to-end solution. Real deployment, real database, real users (even if it’s just five people). This is worth infinitely more than 10 tutorials following the letter.

Specialization with Flexibility

I’m a .NET/C# specialist, but throughout my career I’ve also worked with JavaScript, TypeScript, Angular, React, and now I’m deep into AI. This flexibility allowed me to survive multiple waves of technological change.

Don’t lock yourself into a single stack. But don’t be superficial in everything either. Find your main axis and, from there, expand gradually.

Master one core area (backend, frontend, mobile) but maintain active curiosity. Learn enough about other areas to communicate well with your colleagues. This will make you nearly irreplaceable.

Areas with Real Longevity

If you want long-term stability, some areas are safer bets:

Backend and Infrastructure: There will always be a need for people who understand what happens “under the hood.” I’ve worked with Windows Server since 2003, Azure, DevOps, CI/CD. These skills never became obsolete; they just evolved and became more complex.

Security: The more digital the world becomes, the more critical security is. I took a digital security course in 2019 and still use those concepts daily.

Data and AI: I developed AI solutions back in 2000 (yes, AI isn’t new), now supercharged with generative AI. Today, with LLMs and the current boom, those who truly understand data and can integrate AI practically have a market for decades.

DevOps/SRE: The bridge between dev and operations has never been so valuable. Experience with Azure DevOps, GitHub Actions and CI/CD makes you essential.

The Myth of the 10x Developer

Forget this story if you’ve heard it, of the 10x developer. In my experience, I’ve never met a “lone genius” who delivered 10x more. I’ve met many consistent developers who, over time, generated a massive impact by writing code that others could maintain, sharing knowledge, elevating the entire team’s level and avoiding unnecessary technical debt.

Consistency and collaboration beat genius every day of the week.

AI Changes Everything (But Not How You Think)

I’m currently developing an automated platform for creating SaaS platforms, already thinking about APIs being consumed by other AIs. AI won’t replace developers, but it will replace developers who don’t know how to use AI.

Use tools like GitHub Copilot, ChatGPT and Claude to accelerate your work. But understand what they’re doing. Review the code. Test it. AI is a multiplier, a simple tool, not a substitute for understanding.

Conclusion

• Learn solid fundamentals.
• Build real projects.
• Choose a specialization but maintain flexibility.
• Invest in areas with longevity.
• Develop soft skills.
• Be consistent, not “10x.”
• And use AI as a tool, not a crutch.

I’ve been on this journey for 30 years, and I’m still excited. If you choose this path for the right reasons, a love for solving problems, constant curiosity and the desire to build things, you’ll have an incredible career. Obviously, good compensation matters, but it shouldn’t be your main motivation.

And you? What fundamentals have saved you in your career so far?

Developing applications that can be used by everyone is a goal that any app should keep in mind. When I say “for everyone,” I mean that our applications should be able to communicate a clear and understandable purpose, so that people with or without disabilities can use them without issues. In other words, it’s not just about “making it work,” nor about limiting it to a single way of use (such as only being understandable if you can read the buttons).

You’ve probably heard the term A11y, and maybe you’ve stopped to think… What does it mean? A11y refers to the accessibility of our applications. While it’s much more common to hear this term in the web space, mobile applications should also take it into account to offer a better product.

In this article, you’ll learn more about accessibility, some guidelines you can follow to apply it correctly in .NET MAUI, the aspects you should start paying attention to and why A11y is not an extra, but a fundamental part of the quality of a well-built application.

Let’s Talk More About A11y

A11y is an abbreviated form of the word accessibility, and its goal is to allow people with or without visual, auditory, motor or cognitive disabilities to use your apps. A11Y is a type of abbreviation very common in technology, and it is known as a numeronym.

It works as follows:

• A: is the first letter of the word.
• 11: is the number of characters that come after the first letter and before the last one. In Accessibility, specifically in “ccessibilit,” there are 11 letters.
• Y: is the last letter of the word.

That’s why it is abbreviated as: A11y. This method makes it much more convenient to write long terms in a faster way and helps standardize lengthy terminology.

How Can We Apply A11y in Our Apps?

To implement this in our applications, there are accessibility guidelines such as WCAG, which instruct us on how to adapt the tools that mobile devices already provide so they can work together with our apps.

The Web Content Accessibility Guidelines (WCAG) are a set of international guidelines created by the World Wide Web Consortium (W3C). Although web is part of their name, I always recommend applying these practices to all types of applications, including mobile. Our users will thank us for it.

In fact, the official documentation states the following:

“These guidelines address accessibility of web content on any kind of device (including desktops, laptops, kiosks, and mobile devices).”

The WCAG are built on four fundamental principles, known as POUR. WCAG defines what an application must comply with to be accessible, while POUR helps us understand how to think about accessibility from a development perspective.

These four criteria that make up POUR are:

• Perceivable
• Operable
• Understandable
• Robust

Let’s take a closer look at POUR—what each principle means and some examples of how we can translate them into our .NET MAUI applications:

Perceivable

This principle indicates that all the information in the app (including text and UI components) must be perceivable by the user, regardless of how they interact with the device. In other words, our app should not be based solely on visual information.

This is especially important for users who:

• Use screen readers such as TalkBack or VoiceOver
• Have low vision or use larger text sizes

In .NET MAUI, we have SemanticProperties, which help us a lot with this aspect.

Semantic properties are the Microsoft-recommended approach in .NET MAUI to provide accessibility values in applications. This allows us to add a description to our visual elements so that they can be read by the screen reader.

Additionally, I recommend exploring SemanticOrderView. While the individual reading of each visual element is important, being able to provide the user with a reading order so that this reading is coherent greatly enhances a good user experience. For this, we can use SemanticOrderView from the .NET MAUI Community Toolkit.

Let’s explore some examples of implementing the Percievable principle in .NET MAUI:

Alternative Text for Images and Icons

Images and icons are very common in mobile apps, but for a screen reader, an image without a description is 100% invisible. That’s why it’s recommended to tell the screen reader that there is something there and what it should read.

In the following example, you can see the warning.png image used in the UI. When navigating the app with VoiceOver or TalkBack, this image will be announced as “Warning icon.” For this reason, I recommend being as specific as possible when defining its description.

<Image Source="warning.png"
 SemanticProperties.Description="Warning icon" />

What About Decorative Images?

Not all images provide information. In these cases, we can remove them from the accessibility tree so the screen reader ignores them (meaning it won’t read them):

<Image Source="divider.png"
 AutomationProperties.IsInAccessibleTree="False" />

This helps keep the experience cleaner and prevents the screen reader from reading unnecessary elements.

Headings

Screen readers don’t just “read in order” and stop there; they also allow users to navigate by sections. For this reason, it’s important to mark titles or main sections as semantic headings.

<Label Text="Payment Settings" 
 FontSize="24" 
 SemanticProperties.HeadingLevel="Level1" />

This way, the screen reader recognizes this element as a heading and makes navigation within the screen much easier.

Supporting Scalable Text

In addition to screen readers, there is also a significant number of users with low vision. You may have noticed that some people use very large text on their phones; that’s probably why.

As developers, we can contribute to making our app more accessible by allowing it to adapt to the text size users feel most comfortable with.

For this, in .NET MAUI we have FontAutoScalingEnabled, a property that allows the text in our app to automatically scale according to the system preferences.

<Label Text="Payment Settings" 
 FontSize="24" 
 FontAutoScalingEnabled="True" />

With this, if the user increases the text size from the device settings, the Label will scale accordingly, improving readability and aligning with the Perceivable principle.

Operable

The Operable principle states that users must be able to interact with the app without difficulty, regardless of the way they use the device.

In other words, not all users interact in the same way. Some use screen readers, others use a keyboard or assisted navigation. For this reason, the app should not rely solely on complex gestures or interactions that do not provide a clear alternative.

In mobile applications, this principle basically translates into:

• Easy-to-tap controls
• Clear and predictable navigation
• Avoiding interactions that require extreme precision

In .NET MAUI, many of these best practices can be applied directly using the components we already work with. Let’s see NET MAUI some Operable examples we can apply:

Appropriate Size for Interactive Elements

A very common problem is having icons or buttons that are too small, which limits interaction and can make the app difficult—or even impossible—to use for some users.

For this reason, it is recommended to respect minimum sizes for interactive elements:

• iOS: minimum 44 × 44 pt
  This recommendation comes from Apple’s Human Interface Guidelines, where this minimum size is established for interactive elements such as buttons or tappable icons.

• Android: minimum 48 × 48 dp
  On Android, this recommendation comes from the Android Accessibility Guidelines and Material Design.

In .NET MAUI, we can apply this easily, for example:

<Button Text="Continue" 
 HeightRequest="48" 
 Padding="16,12" />

Or for icon ImageButton:

<ImageButton Source="close.png" 
 WidthRequest="48" 
 HeightRequest="48" 
 Padding="12" 
 SemanticProperties.Description="Close" />

Understandable

This principle states that the information and interactions within our app must be easy to understand.

Why is this important?

• Not all users have the same technical level.
• Some may have cognitive difficulties.
• Others are simply using the app for the first time.

In mobile applications, this principle mainly translates into:

• Clear and direct text
• Consistent navigation
• Predictable actions
• Error messages that explain what happened and what to do next

Some examples of Understandable in .NET MAUI:

Clear Language in Text and Labels

Avoid ambiguous or overly technical texts (I’ve literally seen “state error” in apps … that should not happen), especially in buttons and important messages.

For example, for a save button, use text that clearly describes the action:

<Button Text="Save changes" />

Once the save action is executed, if an error occurs, don’t leave the user guessing or hanging. Tell them exactly what happened.

❌ Saving changes failed

✅ The name field cannot contain special characters

The idea is for the user to understand what happened and what the next step is, without having to interpret technical messages.

Robust

This principle states that the app must be robust enough to work correctly across different environments or devices. In other words, the app should continue to work when:

• It runs on different versions of the operating system
• It is used with screen readers such as TalkBack or VoiceOver
• It is used across different platforms
• It adapts to different screen sizes (small, medium and large) without affecting usability or content clarity

An example of the Robust principle in .NET MAUI is the use of OnPlatform.

OnPlatform

Although .NET MAUI abstracts many platform differences—and personally, I try to use OnPlatform as little as possible to keep maintenance easier across Android and iOS, always looking for visual elements that give me the same result—in some cases, Android and iOS behave differently, and using it becomes necessary.

If you run into that situation, you can use OnPlatform to keep the behavior on both platforms exactly how you want it:

<Button Text="Continue" 
 HeightRequest="{OnPlatform iOS=44, Android=48}" 
 Padding="{OnPlatform iOS='16,12', Android='16,14'}" />

This way, you respect each platform’s recommendations while keeping an accessible and consistent experience, aligned with the Robust principle.

Conclusion

And that’s it! In this article, we talked about A11y and why accessibility should be part of how we build mobile apps with .NET MAUI, not something added at the end. By understanding the POUR principles we saw how accessibility can be applied through small, intentional UI decisions.

From making content perceivable and interactions operable, to keeping things understandable and keeping our apps robust across platforms, each choice helps create a better experience for more users.

Remember: users may not know what A11Y is, but they definitely feel it when an app is accessible.

See you in the next article! ‍♀️✨

You’ve probably felt that anxiety of seeing new technologies blowing up on X/Twitter or LinkedIn and thinking, “Do I need to learn this now? Will I fall behind if I don’t?” This feeling of tech FOMO (Fear of Missing Out) is real and can be paralyzing.

I’ve seen countless technologies born with revolutionary promises and die within a few months. Professionals invest hundreds of hours in frameworks that never gain market adoption. And people ignore genuine trends due to excessive cynicism, falling behind.

The truth is there’s no magic formula. But there are signs, patterns and strategies that can help us make more consistent decisions.

Signs of Real Traction vs. Hype

Let’s start with the most important thing: how do you differentiate between superficial social media buzz and genuine market adoption of technology?

The Social Media Theater

X/Twitter and LinkedIn have become stages for tech performance. Influencers gain followers by talking about the “next big thing.” Marketing companies pay for sponsored posts disguised as genuine opinions. Developers seek visibility by betting on technologies that seem innovative.

Note that these platforms have value. Often, that’s where we first hear about technologies that become important. The problem is that’s also where we hear about hundreds of others that never go beyond buzz.

Think about how many times you’ve seen enthusiastic posts about some technology that promised to “change everything” and, six months later, nobody was talking about it anymore.

We have a somewhat recent case with the metaverse: major initiatives, companies selling spaces, billions in investments, and when generative AI arrived, all that metaverse hype went down the drain. Nowadays, nobody even talks about it anymore. That’s the nature of social media; the attention cycle is short, and the next hype is always just one post away.

That’s why I developed the habit of not reacting immediately to what I see on social media. I used to panic when I noticed I was missing the train of modernity. Today, I’m more cautious; I take notes, observe, but don’t invest significant time until I see more concrete signs.

I remember the days of Visual Basic and the early days of C#, where I noticed an interesting pattern in Microsoft products. It was usually from version 6.0 that a tool reached maturity or disappeared.

Visual Basic 6.0, for example, was the peak and the end of the line for that VB model. C# followed a similar path; version 6.0 brought the stability the language needed. Then came a transition period with .NET Framework (up to version 7.3), followed by a “rebirth” in .NET Core starting with C# 8.0, and today we’re at C# 14 running on .NET 10.

Indicators of Genuine Adoption

I use two indicators about technology usage by observing the market:

Company Hiring

Companies don’t hire for technologies they don’t intend to use. When you start seeing job postings on platforms like LinkedIn, Indeed or Glassdoor asking for experience in a particular technology, it means there’s real demand.

But be careful. It’s not enough to see a few postings. What matters is observing the trend. Is technology appearing in more job postings over time? Is it being requested by companies from different sectors and sizes? Is it appearing in senior positions or just in startup experiments?

The 2-Year Filter

This is probably the most straightforward and most powerful strategy: wait at least two years before diving deep into any new technology.

Why 2 Years?

It’s not a magic number, but there’s logic behind it. The first year of any new technology is the honeymoon period. There will be enthusiasm, hype and excited early adopters. The real problems haven’t appeared yet because nobody has had enough time to find them.

In the second year, reality starts to show. The first production projects reveal limitations. Companies that adopted early begin sharing their experiences, including the pain points. Competitors have time to react and offer alternatives.

If technology is still growing and being adopted after two years, it has passed trial by fire. It survived the initial hype cycle, proved to have real value and developed a sustainable community. It’s a much safer bet.

Exceptions to the Rule

Of course, no rule is absolute. There are situations where it makes sense to adopt technology earlier:

• When you work in a cutting-edge field and being at the forefront is part of your competitive advantage, it may make sense to take more risks. AI startups, for example, frequently need to adopt emerging technologies before they mature.

• When technology solves a critical problem you have right now, and there are no mature alternatives, sometimes there’s no choice but to accept the risk.

• When you have resources to invest in learning, even if technology goes nowhere, like personal projects or hackathons, the cost of being wrong is low.

But for most professional decisions, especially those involving production projects or long-term career development, the two-year filter remains an excellent option.

How to Follow Without Diving In

Waiting two years doesn’t mean completely ignoring technology during that period. It means following from a distance, being aware of what’s happening, without investing significant time in deep learning.

In practice, this can mean reading introductory articles to understand the basic concepts, following the leading developers and the official account on X/Twitter, watching one or two introductory talks, adding some repositories to your favorites to keep track of, and participating in superficial discussions when the topic comes up.

This lighter following approach lets me stay informed as technology matures without wasting hundreds of hours if it doesn’t take off.

The Complexity Bias Trap

There’s a trap around our necks. Sometimes, we choose complex technologies because they seem more sophisticated or because they challenge us intellectually. But unnecessary complexity is a cost, not a benefit.

The right question isn’t “Is this technology impressive?” but “Is this technology appropriate for my problem?” Often, the simplest solution is the best.

Kubernetes is incredible, but do you need it for your application? Microservices are elegant, but does your project justify the complexity? The most advanced technology isn’t always the most suitable.

Conclusion

The best strategy for identifying technologies worth pursuing is to combine cautious observation, analysis of concrete adoption signals and patience to let time filter what’s truly relevant.

What we can always rely on is maintaining a growth mindset and learning from new technologies; even if they disappear, we’ll still carry a bit of their way of thinking into the next phase of life’s game.

And you? How many times have you seen technologies emerge, disappear or continue to this day?

I read a post on Reddit the other day from an enterprise UX designer. They’d just landed a new gig with more money and a lead title that felt like a promotion. On paper, it sounded like progress. But the reality hit fast. Just patch-and-fix work. Migrating Excel sheets into out-of-the-box tools and calling it innovation.

What they wrote stayed with me:

“My design soul feels like it’s dying. No passion, no creative spark. I feel like I’m drifting further and further from what drew me into UI/UX in the first place.”

That feeling is more common than people admit, and it often hits right after you climb the ladder.

The Climb That Feels Like Progress

Most designers climb the career ladder for understandable reasons. You get promoted into a lead position or move from startups into enterprise UX. You gain a bigger title, more stability, better pay and benefits.

With that comes the promise of impact and influence.

The early days seem fine. You’re suddenly exposed to large programs and complex systems. You deal with new domains and teams spread across regions. You sit in strategy meetings. You meet senior leaders. The climb gives you a sense of elevation. It feels like the right choice. It feels like progress.

You tell yourself you’re finally doing meaningful work. You’ve earned a seat at the table.

But there’s a quiet trade-off most people don’t notice. Only when you’re far enough up that you start feeling down.

The Valley of Despair

At first it’s the small things: more meetings, more alignment sessions and more approvals.

Your solution is defined by licensing agreements rather than user needs. Requests that are really just vendor configurations. Your influence shrinks even as your title grows. You feel the ceiling closing in.

The spark that pulled you into design—the curiosity, creativity and craft—starts to fade.

You still care. You still want to do great work. But the environment around you wants the result, not the process.

And then the questions arrive:

• Is this really how design works?
• Is this what I want to do?
• Where’s my passion?

It’s not a sign that something is wrong with you. It’s a sign that something’s happening to you.

And it has everything to do with scale.

The Mechanics of Scale

Enterprises operate very differently from individuals driven by craft.

At scale, companies optimize for predictability, repeatability and risk reduction.

• Unity over uniqueness.
• Stability over innovation.
• Delivery over craft.

Not because leaders hate your creativity. Not because designers aren’t valued or design isn’t wanted.

But because reducing variance makes it easier for thousands of people to move in the same way. Your passion—your desire to shape and craft—doesn’t fit easily into that machine.

The mechanics of scale lack the sensitivity for meaning. It feels like you’ve lost your passion or miscalculated your career. It’s easy to see this as a personal failure.

But the truth is you didn’t change. The environment did. And the way out begins with seeing it differently.

Back to Your Roots: Empathy

When designers feel lost, we often forget the tool that built our discipline: empathy.

Empathy is what lets you step out of your own head and see the world through someone else’s eyes. It’s how you reinterpret your reality, how you can recalibrate your perspective.

Empathy for the User

Start with someone else’s frustrations—your users’.

Their frustrations and needs give you back a sense of clarity about why your work matters. Their perspective lets you see who you’re really doing this for.

That Excel sheet, migrated into a cloud-based dashboard, might not change your life. But it can change theirs.

Users remind you that you still make an impact, even when it feels like you can’t fully practice your craft.

Empathy for the Business

Turning your empathy toward the business is less comfortable.

Understanding the business means acknowledging its constraints, priorities and pressures. It helps you see why innovation is slow, what the stakes are and what your boss is dealing with.

Empathy for the business doesn’t mean you capitulate. It lets you understand.

Understanding how the business works doesn’t fix everything, but it does reduce resentment. And resentment’s what holds you back.

When you see the system clearly, you stop interpreting constraints as personal attacks. You stop assuming incompetence. You recognize the environment around you.

And once you grasp that environment, you can design within it.

Empathy for Yourself

This is the hardest one.

Your own perspective is the one you can’t step away from. Your emotions are the ones you can’t ignore.

• Why does this feel frustrating?
• What exactly is painful here?
• Where am I feeling loss?

Self-empathy is more constructive than self-criticism. It makes you aware of your inner state.

And once you can see why you’re truly frustrated, you discover something greater than passion: purpose.

From Passion to Purpose

When you feel stuck, it’s tempting to think that “finding your passion” will fix everything. But passion alone won’t get you out.

The word pathos, the root in words like “empathy,” is about feeling and suffering—about what happens to you. It’s emotion.

And emotion comes from emovere: ex (out) + movere (move).

Emotion moves outward. It reacts. It signals. But emotion alone doesn’t move you forward. Purpose does.

Purpose comes from proponere—to put something forward. To place something ahead of you. To guide your next step.

Passion is what you feel in the moment. Purpose is what you do with that feeling.

And this is where empathy becomes a bridge. Empathy helps you look at the same reality and read it differently. It lets you recalibrate your perspective instead of staying locked in frustration. It shifts you from “how I feel” to “how I move.”

Once you understand the people you impact, the business you operate in and the reason you feel stuck, you have the first pieces of the puzzle that uncover your purpose.

Purpose isn’t a statement. It’s what moves you forward.

And once you see it, you can redesign your job, your role and your path. Even within constraints, you can bring that purpose forward.

Forward, Not Up

Early in my career, I saw the path the same way everyone else did: a ladder.

Later, when I was leading others on their path, I learned to nuance the direction. Not everybody thrives on an upward trajectory. Some are better off moving sideways. So I tailored progress and growth to the individual—vertical and lateral progressions.

But here’s the truth I learned far too late: Up, down, left or right don’t automatically mean forward.

I redesigned my career multiple times. Carved out new roles inside the same company. For years, it worked. Until it didn’t. My reality was defined by the mechanics of scale. I found myself stuck in the valley of despair.

So I left. No new job lined up. No master plan. Just space.

And in that space, I finally had enough room to look inward. To understand what I needed to do. To renew my perspective.

I rediscovered where I could move on purpose. I’m still defining that purpose. It’s still taking shape.

Closure

My career’s no longer about moving up. It’s about moving forward.

Not how I feel about what I do, but how I move with what I have to do.

That’s what progress is about: not just finding passion, but moving on purpose.

At 17, I picked up my first book on Neuro-Linguistic Programming (NLP). Not because a mentor recommended it or out of philosophical curiosity, but because I wanted to understand how I worked and what I could become. I found the world meaningless and thought my problems were too big for me to handle. The book introduced me to an idea that seemed too obvious to be true: If you have a problem, you can solve it. Life doesn’t hand you burdens you can’t carry.

It took me years to understand what that really meant. And even more years to realize that this lesson wasn’t just about fixing code bugs.

What I’m sharing here comes from my personal experience, mistakes included. It might not apply to you, but if even one of these reflections makes you pause and think, it’s worth it.

Know Thyself (Before Life Forces You To)

“Know thyself”: Socrates said this millennia ago, but nobody teaches you how to do it in school. And for developers, this self-knowledge isn’t a philosophical luxury. It’s a survival tool.

Today, I know what sets me off in a code review. I know how I react when someone questions my architecture. I understand why I prefer working on complex features alone before presenting them to the team. But it took me a long time to get here.

The problem is that we’re several different selves: The developer who defends their technical choices tooth and nail, the team member who needs to compromise in discussions, the professional who accepts projects they don’t like to pay the bills, the friend, the son, the father. Each of these selves has its own behavior patterns. And you only discover these patterns by going through experiences, preferably by seeking them out instead of just waiting for them to come.

Early in my career, conflict situations left me stunned: How can people not see the clarity of my idea, the way I see it? Defending a different technical idea seemed like arrogance. But over time, I learned something counterintuitive: I started to enjoy conflicts. Because it’s in friction that you discover what your ideas are really made of. It’s when people lose their cool that they show who they are, and so do you.

But this only makes sense when you know yourself. When you know what your path is.

And this is work only you can do. There’s no YouTube tutorial, no framework. It must come from within.

Some Questions That Helped Me (And Might Help You)

Is what I do/work aligned with what I feel?

Not in the romantic “do what you love” sense, but in the honest sense: Does this move me or anesthetize me?

Do my opportunities make me grow?

Or am I just repeating what I already know how to do because it’s comfortable?

What do I have to learn where I am today?

If the answer is “nothing,” you should have already left.

An important aside: There’s a dangerous belief that “doing what you like” is a privilege for billionaires. That you need to suffer first, make money later and only then can you afford the luxury of liking what you do. That’s a lie.

The point here is that successful people did do many things they didn’t like, yes. But that’s not why they succeeded; it’s despite it. And curiously, neuroscience shows that doing things you don’t like (like washing dishes) strengthens your ability to deal with adversity. Children who have household responsibilities develop greater resilience and entrepreneurial tendencies.

The point isn’t to avoid discomfort. It’s knowing why you’re doing what you don’t like, whether it’s a means to a clear end or just an escape from the decision to know yourself.

Solitude Isn’t the Enemy (It’s the Laboratory)

Developers have a strange relationship with solitude. Our profession pushes us toward it, hours in front of the screen, headphones on, immersed in problems that only exist in our heads. And at the same time, they tell us we must be “collaborative,” “work as a team” and “do pair programming” (which, personally, I think is excellent).

The truth I learned is that any person’s life, no matter how social they are, is fundamentally solitary. Nobody’s going to be responsible for your commitments, your architecture choices or your career. You must count on yourself most of the time.

This doesn’t mean you don’t need friends or a team. It means you need to learn to live with yourself first, and that’s a challenge.

And for developers, this skill is even more valuable. Because developing technically is more about thinking than acting. When you’re programming, solving a complex bug or architecting a solution, solitude isn’t isolation; it’s focus. You don’t need constant interaction to deliver. In fact, interruption is often the enemy.

But, and this is crucial, you can’t think everything through alone. A healthy dose of team interaction is necessary. The trick is knowing when to be alone and when to seek others out.

Things I did to master my relationship with solitude: Going to the movies alone, to restaurants, to concerts. It sounds silly, but it’s not. It’s about learning to appreciate your own company. It’s about creating inner life.

Artur da Távola, a Brazilian thinker, said: “Music is inner life, and whoever has inner life will never suffer from loneliness” (free translation).

Quality moments alone, without electronics, without notifications, just you, good music or a good book, make a difference. It’s in this silence that you process the day’s conflicts, understand why that meeting irritated you, and notice patterns in your behavior.

Solitude isn’t punishment. It’s the laboratory where you get to know yourself.

Early Success: The Invisible Trap

At 21, two years after entering the IT field, I started my own company. Money came fast. A lot of money. It seemed like I had cracked the code of life.

That success stagnated me.

Early success is a dangerous drug. It addicts your brain. It fills you with false confidence because you don’t yet understand that success has context, timing and luck. You think it was all competence.

The problem isn’t success itself; it’s not realizing that the premises that got you there won’t be present at the next level. You level up, but want to play with the same strategies.

I wasn’t prepared for the next level of growth. I didn’t know how to scale people, processes and complexity. And when a serious accident caused me to stagnate for nearly a decade, I realized I had built castles in the sand.

It was during this forced pause that I did the best work of my career. I focused on developing a legal system with features nobody else had: a complete change in history, field by field, and thousands of features meticulously thought out in the most minor details. Advocati was considered the best legal software in Brazil in 2007.

But it took me until 2011 to return strongly to the market.

Those years taught me something brutal: Enjoy your success, but don’t be blinded by it. Don’t become arrogant. Lower your expectations that everything will always work out. This gives you a more realistic view.

I’m not saying dream small. Dream big, but take solid, consistent steps. Our lives are increasingly fluid, and constantly changing goals and objectives get you nowhere. Having a fixed target and mapping out the right strategy to reach it, without illusions, is the safest path.

And there’s something else: You’ll repeat your mistakes until you learn the lesson. Your life is teaching you something. If you don’t understand or don’t even realize there’s a reason behind your challenge, you’ll keep repeating the same cycle.

Life isn’t a game where you pass levels. It’s more like debugging as you run the code, see where it breaks, adjust and then rerun it. The problem only disappears when you understand its root cause.

What to Do With All This?

Knowing yourself isn’t a destination. It’s a daily journey. It’s noticing when you’re reacting on autopilot. It’s questioning why that comment on PR irritated you so much. It’s having the courage to be alone with your thoughts. It’s celebrating success without thinking you’ve become invincible.

When the next conflict comes, the subsequent failure, the next success, you’ll have something most developers never build: clarity about who you are when nobody’s watching.

What I’ve shared here comes from decades of learning. Your journey will be different. But if you start getting to know yourself now, maybe you won’t have to wait for an accident to learn what took me decades to understand.

What’s Next for Me?

Having learned my lesson, I’m always looking for new ways to challenge myself.

Today I’m working on an exciting AI project that’s pushing the boundaries of modern development, an intelligent SaaS platform creator powered by natural language prompts. This innovative tool leverages .NET 10 for a robust backend, Microsoft SQL Server for enterprise-grade data management, and React with Next.js on the frontend, all brought together with the rich UI components of the Progress KendoReact library.

The vision is simple yet powerful: Describe your SaaS platform requirements through prompts and watch as AI transforms your ideas into a fully functional, production-ready application, complete with professional interfaces powered by AI and scalable architecture.

To validate the project, we’re developing and refining it alongside five real-world systems built with this new product.

And I look forward to learning about myself in the development of this project.

What’s next for you?

Maybe you know the acronyms: TDD, BDD or DDD. If not, go on Reddit and you will find enough debates to learn it keeps our industry busy.

Each acronym shifted how we think and how we build software. Now, with new accessibility laws setting a hard deadline, it’s time to add one more: ADD. Accessibility-Driven Development.

Compliance as a Driver of Quality

For years, accessibility was treated as optional or “nice to have.” A box you ticked if you had time. But history shows us that regulations and compliance raise quality and drive standardization.

Think about hardware safety regulations or industry protocols. At first, they seemed like a burden. But once enforced, they became the baseline that allowed whole industries to build better. Today, shipping is faster than ever. Compliance is the safeguard that helps prevent quality from being skipped.

A Time Change in Accessibility

If you’ve worked in UX or frontend development, you’ve probably heard of the Web Content Accessibility Guidelines (WCAG). They’ve been around for decades, laying out the rules: make software perceivable, operable and understandable.

WCAG has been the global guideline for accessibility. But for years, adoption was inconsistent. Companies did what they wanted, or what they could afford.

That changes now. The European Accessibility Act (EAA) is in force as of June 28, 2025. It harmonizes accessibility requirements across the EU and sets real deadlines for compliance. This is the moment accessibility shifts from voluntary guidance to enforceable law. A time change for the industry.

In the U.S., the Americans with Disabilities Act (ADA) has fueled a rise in lawsuits over inaccessible websites and apps. Similarly, Section 508 of the Rehabilitation Act requires federal agencies and contractors to conform to WCAG. Between lawsuits and procurement contracts, WCAG has become the standard in the U.S. too.

Different routes, same outcome: WCAG tells us that we need better software for everyone.

The Disciplines We Already Know

Disciplines reshape the way we develop software. They’re mindsets that force us to shift perspective and raise the quality of the software we ship.

TDD: Test-Driven Development

With TDD, we write failing tests before we write code. It flips the order. Instead of coding first and testing later, we define the boundaries up front.

The discipline: build resilience by considering how software might fail.

BDD: Behavior-Driven Development

BDD takes this further. Instead of only testing functions, we write scenarios in plain language: Given, When, Then. It’s not only developers who can understand, but also stakeholders, product owners, testers.

The discipline: align software with real user expectations.

DDD: Domain-Driven Design

DDD steps back another layer. It tells us: don’t just model features, model the domain itself. Speak the same language as the business. Reflect its truth in your system.

The discipline: design software that mirrors business reality.

Each of these disciplines changed how we think. They aren’t just tools; they’re shifts in mindset.

ADD: Accessibility-Driven Development

Now it’s time for the next discipline: Accessibility-Driven Development.

ADD means designing and testing for the edge user first—the one with constraints. The one who doesn’t use your product the way you do. If it works for them, it will work for everyone.

Think of it like TDD. In TDD, you write a failing test first. In ADD, you define the hardest case first.

Keyboard-only navigation becomes your failing test. A screen reader flow becomes your scenario. High-contrast mode becomes your business constraint. You design and build until those pass.

ADD shifts the mindset. Accessibility isn’t something you sprinkle in at the end. It is a discipline that shapes decisions during building.

The discipline: build software that is accessible to many, not to some.

Why ADD Matters Now

Why now? Without the European Accessibility Act, many teams would keep treating accessibility as optional. But with compliance dates set, ignoring accessibility is no longer a choice.

ADD helps you shift from reactive to proactive. Instead of scrambling with audits and lawsuits, you build accessibility into the process. Compliance becomes a habit, not a fire drill.

Here’s the point: designing for edge cases improves the experience for everyone. It’s called the curb cut effect. Those sidewalk ramps built for wheelchairs are also used by parents with strollers, travelers with luggage and kids on scooters.

You’re not wasting resources on a minority. You’re building better software. Accessibility isn’t overhead. It’s an advantage.

By designing for the most constrained environments, you raise the quality of the entire system.

Closing

Accessibility is not a gesture. It’s a discipline.

A new standard to comply with in software. And compliance has always been a driver of quality. Industry protocols in manufacturing. Safety standards in hardware. Now, accessibility in software.

You don’t have to choose between TDD, BDD and DDD. They’re not a menu. They’re a collection of development disciplines that shape how we build.

The one you need to add next is ADD: Accessibility-Driven Development.

Whether you just landed your first job as a designer/developer or you’ve been working for years, impostor syndrome can hit at any time. All it takes is for just one seed of doubt to be planted before you start wondering, “Am I even capable of doing this job? No one thinks I’m any good anyway. Maybe I should quit, save them the trouble.”

The problem with impostor syndrome is that it’s more than just negative self-talk. If it goes on for long enough, it can cause significant damage to your mental health, relationships and career.

So, rather than feed into this vicious cycle of tearing yourself down, let’s discuss some strategies that can help you get past impostor syndrome.

What Is Impostor Syndrome?

According to McLean Hospital:

“When someone has impostor syndrome, they experience repeated feelings or thoughts that they are incompetent or not good enough, despite evidence to the contrary. These beliefs often have roots in someone’s personal history and tend to play out in work, academic, and other high-pressure settings. Unaddressed, they can keep people from enjoying their successes and living life to its full potential.”

What do these feelings of insecurity and self-doubt sound like? Here are some examples:

• “I’m not good enough.”
• “I don’t belong here. Everyone is smarter than me.”
• “Everything I build is awful.”
• “I guess I charge … $12 an hour?” (Because you can’t imagine anyone paying you a fair wage for your work.)
• “I’m a complete disaster.” (After making a small mistake that no one noticed.)
• “I can’t ask for help because then they’ll realize I don’t know anything.”
• “Any day now they’ll figure out I’m a fraud.”
• “[Coworker] always does a better job. They should just give them all the important jobs.”
• “It didn’t have anything to do with me. It was all because of …” (When someone gives you a compliment.)
• “Here’s the onboarding mockup I created. It’s not very good. I’m sure you won’t like it.” (When presenting your work to a client.)

Impostor syndrome doesn’t just manifest itself in the words you speak about yourself or work. It can also create anxiety and depression, lead to insomnia and negatively impact your work performance. In addition, it can burn you out.

According to the American Psychological Association (APA), it can also make people not want to work with you. Not because you’re not good at what you do. But because your attitude is draining and they feel like it’s impossible to connect with you.

It’s almost as if impostor syndrome becomes a self-fulfilling prophecy. While managers, coworkers and clients may not have had a problem with the quality of your work before, they will once it and your attitude degrade over time.

How to Keep Impostor Syndrome from Getting in Your Way

Starting to feel the side effects of impostor syndrome at work? Here are some things you can do to get it out of your way (and out of your head):

1. Focus on What’s True, Not on What You Feel

Let’s take one of the example sentiments from above:

“Everything I build is awful.”

Let’s say this thought keeps crossing your mind every time you turn something into your supervisor or client.

The first thing to do is to recognize that this is a thought and nothing more. Unless you have a client shouting at you that you are indeed awful every time they see your work, this is your own criticism you’re dealing with.

Next, focus on what’s factual:

• What are the five last projects or tasks you completed?
• What was the feedback you received on them from others?
• In the end, was your employer or client satisfied with the end result?

You can’t argue with facts. So, the next time you start with the negative self-talk, call to mind what you’ve been working on and how it was received. Actually look at the paper trail from the project to work with facts and don’t just recall memories that may be tainted by your feelings.

Also make note of major wins and write them down somewhere. Positive client testimonials. Referrals from a client you worked closely with. Management congratulating you in front of the team. A bonus at the end of the year. As they stack up, it’ll be hard to call yourself an impostor.

2. Talk to Someone You Respect

If you’re seriously doubting the quality of your work, bring it to someone you admire and respect in your field. And avoid sharing it with someone whose opinion you could easily discard, like a loved one. (“Oh, they just said that so I wouldn’t feel bad.”)

There’s no need to share your opinions or criticisms about the work with your peer. Instead, just bring it to them with the hope of getting unbiased feedback, and see what they say.

To start, if they pay you any compliments, graciously accept them. Remind yourself that they have no reason to lie to you or sugarcoat the truth. They are someone you respect and whose opinion you trust. They get nothing out of lying to you.

If they give you feedback, remember that feedback does not equal failure. We all get feedback, even when we’re experts at the top of our careers. Thank them for their feedback, make note of the input you received and then spend time reviewing it.

Put aside your negative self-talk and evaluate the feedback against reality. Is it fair? If so, what can you do to address it and improve?

This is what feedback is for. It helps us better understand our strengths and weaknesses, and to put a plan in place so we can move forward better than before. Not to wallow in perceived criticism.

This is the difference between an impostor and an expert. The impostor won’t know what to do with the feedback or how to grow from it. The expert will. They’ll also have the motivation to do so, too.

3. Ask Your Manager or Peers for Support

Let’s say your feelings of impostor syndrome have come from something that your manager, clients or peers have said to you. This again comes down to whether you’ll allow that feedback to fester or to put it to good use.

For example, let’s say that your manager hasn’t been pleased with your creation of color palettes. If they haven’t given you feedback on how to create them, reach out for support and guidance. Or you can turn to your coworkers for assistance.

Find out what exactly their expectations or preferences are. Ask about their personal process for crafting color palettes. See if there are specific tools they recommend you use.

If you’re feeling inadequate, don’t give up. See if you can get someone to guide you toward a new process or practice.

On the other hand, let’s say your feelings of impostor syndrome have come from something that your manager has said or done, but it wasn’t a direct criticism.

For example, they reassigned one of your tasks to a peer. Do you know for sure why they did it? If you don’t, follow up with them and see if they’ll give you a reason and some feedback. By actively seeking feedback, you may just discover it was a matter of them better allocating resources versus it being a reflection of the quality of your work.

Seeking out the truth can always help when impostor syndrome is getting in the way. It’ll either let you know that your feelings of self-doubt are unfounded or that you do have some areas where you can improve. You lose nothing by asking for guidance and help, and everything to gain.

4. Let Go of Perfectionism

It’s not realistic to seek perfection. Or to wait to turn something in until it’s perfect.

I’m not saying that your work should be full of errors or half done. However, if you’re waiting to reach that so-called perfect version of a website, app, logo or whatever it is you’re building, and then freak out after hitting “Send” because you realized the font size was slightly off, that’s a problem.

We all make mistakes and there are flaws in a lot of the work we produce for the web. We’re human. It’s what happens. So long as you’re paying attention to your clients’ needs and preferences, adhering to best practices and web standards, and doing your level best each time, that’s all that matters.

Once you accept this, you’ll realize it’s not right to put yourself down or abuse yourself for every perceived mistake.

To reiterate what I mentioned before: If it really bothers you to discover a mistake after turning in your work, make note of it. Is there something you can do next time to avoid it?

For instance, let’s say the font in your contact form doesn’t match the font used throughout the Contact page. There’s an easy way to address this particular problem in the future: Revise your process. Instead of manually applying font settings as you add new components, employ a global standard and design system that controls the fonts used throughout.

Let go of this idea of perfection and embrace a mindset of growth and improvement. Find something you don’t like about your process or approach to design or development? Fix it. Don’t let it become something that contributes to the harmful impostor syndrome growing within you.

5. Fake It Until You Make It

For this point, I’m not encouraging you to sell yourself with lies about your background or what you’re capable of. Impostor syndrome relates to feelings of inadequacy when you are already more than adequate, not when you set yourself up for a job you were never a good fit for.

What I mean by “fake it until you make it” is faking confidence and satisfaction with your work.

For example, let’s say it’s time to present the fintech mobile app you created to the client. Don’t present it to them with doubts and negative talk. Instead, take the lead, get excited about the app and show them how amazing it is.

I used to work in customer service and one of the things they used to teach us was to smile every time we picked up the phone. I know, it sounds silly. It’s not like the customer can even see you smile. But there’s research that suggests that forcing a smile on your face can actually impact the way you feel and how you carry yourself.

The same thing can happen when you fake confidence and happiness with your work. By forcing yourself to push the impostor thoughts and statements aside, you get into the habit of reflecting positively on what you do. And once you see that supported by how others react to your work, eventually you’ll realize you were never an impostor.

Another thing to do is catch yourself whenever you use negative words to describe yourself or your work, like “I can’t,” “I hate” or “I won’t.” Rephrase them using positive words. Even just reframing the situation and your thoughts can have a positive effect on your mindset.

This can have long-reaching effects on your career, too.

For instance, once you gain confidence in the everyday tasks you do, you can take things to the next level. With this confidence, you’ll be able to take more risks and accept more challenges. And if you’re hit with another wave of impostor syndrome, don’t sweat it. Even if it doesn’t feel right, your mind will eventually catch up with what everyone else already knows and believes about your capabilities.

Wrapping Up

You are not an impostor. Those feelings and thoughts you’re having? Most creatives get them at some point in their career.

In the beginning, those doubts may come from being a newbie when everyone else around you seems to have it all figured out. It’s natural to wonder if you’re good enough and how long it’ll last as it seems too good to be true.

What’s more, working as a creative is a lot different from, say, an accountant who works with hard facts and numbers. You’re coming up with something completely new. While you’re building something for a client or employer to use, it all comes from within you. And it can be hard to separate yourself from the outcomes or feedback associated with your work.

Impostor syndrome is going to happen. What matters is what you do with it.

I really enjoyed this quote that Dr. Ami Rokach of York University gave to the APA as it shows how impostor syndrome can be turned into a positive:

“Impostor phenomenon is a spectrum, not binary. Just as high achievement can fuel impostor phenomenon in self-doubting people, impostor feelings can fuel high achievement, which would enhance one’s beliefs in his or her abilities and achievement.”