Blog

The Next Scarce Skill Is Not Building. It Is Designing What Deserves to Exist

As building gets cheaper, the advantage shifts toward judgment: deciding what deserves to exist, making it legible, and cutting what weakens it before it ships.


Share this article

Cheap output does not make judgment less important. It makes weak judgment more expensive.

I recently worked through an Android app build where the hard part was no longer getting the app to function. The harder problem was interpretation: making the product understandable, coherent, and trustworthy before a user had invested enough time to fully understand it.

That felt revealing. Software is getting easier to produce, but finished products are not getting easier to differentiate. Many teams still underestimate that shift.

The next scarce skill is not building. It is designing what deserves to exist.

By design, I do not mean visual polish alone. I mean product judgment, scope discipline, workflow clarity, and narrative coherence: the ability to make something understandable, usable, and compelling enough to earn attention.

That does not make engineering less important. It means the economics of software are changing, and when economics change, bottlenecks move.


Building got cheaper. That changed the question.

The important change in software is not just that weak builders can fake momentum faster. It is that capable builders can now produce far more supply.

Experienced developers with strong tooling, mature infrastructure, reusable components, better deployment platforms, and AI assistance can ship serious software much faster than before. That part is real.

As I argued in The Illusion of Progress in Modern Web Development, building is no longer the privileged activity it used to be.

Once building becomes abundant, the defining question changes. It stops being:

  • Can we build this?

It becomes:

  • Should this exist?
  • In this form?
  • For these users?
  • With this scope?
  • At this quality level?

That is a design question.

Not in the narrow “pick nicer colors” sense, but in the harder sense of deciding what deserves to become real.


Cheap output raises the penalty for mediocre thinking

AI has made this easier to see.

Cheaper software does not reduce the cost of bad decisions. It makes them easier to repeat at scale. That is the more important economic consequence of abundant building.

Lower production cost does not just create more opportunity. It also increases the penalty for mediocre thinking, because teams can now move much faster toward:

  • the wrong feature set
  • the wrong onboarding flow
  • the wrong information architecture
  • the wrong story about what the product is
  • the wrong market presentation

And the market punishes those mistakes faster too. Users compare more options, expectations rise, attention fragments, differentiation windows shrink, and weak positioning becomes visible almost immediately.

This is the part many teams still miss. They see lower production cost and assume the whole system got cheaper.

It did not.

As with the broader AI economics behind AI Was Fast. Cheap Was the Part That Broke, faster generation and lower friction do not automatically produce better operating outcomes.

They can just as easily produce more noise: more half-finished tools, more undifferentiated apps, more products that technically function but do not land.

Cheap output does not make judgment less important. It makes weak judgment more expensive.


Users do not experience your architecture. They experience coherence.

One reason this matters is that users never interact with your internal confidence. They do not experience your component structure, your clean repo boundaries, or your deployment pipeline.

They experience:

  • confusion
  • hesitation
  • friction
  • copy that explains too little or too much
  • screens that technically work but do not feel obvious
  • onboarding that asks for effort before trust exists

A product can be technically solid and still feel unresolved. This is where a lot of modern software quietly fails.

I saw this clearly while working on a service marketplace app called LinkedNear. A user could hire locally, offer services themselves, or do both depending on context. The workflow underneath supported that flexibility. The introduction did not.

Instead of clarifying role and next action, the app showed nearby people with actions like “add as friend.” Users could not immediately tell whether the product was for hiring, offering, networking, or some vague local social layer. The system may have functioned technically, but the product introduced itself with the wrong mental model.

Not at the implementation layer, but at the interpretation layer.

The user reaches the product and cannot immediately answer the questions that matter:

  • What is this?
  • Why should I care?
  • What should I do next?
  • Why should I trust this?

That gap is usually described as UX. But UX is really the visible surface of product judgment. It is where a team’s decisions become legible.

When those decisions are weak, the product feels harder than it should, even if the engineering is excellent.

The market is not starving for more apps. It is flooded with them.

What is still scarce is coherence: products that feel focused, communicate themselves clearly, and know what they are for, who they are for, and what friction they are willing to keep or remove.

That kind of coherence is usually produced by restraint:

  • cutting scope
  • tightening language
  • aligning interface behavior with user intent
  • protecting simplicity when the team is tempted to keep adding

That is also why early over-engineering is so expensive. It increases surface area before clarity exists.

Abundant building raises the value of restraint because movement is cheap now. Finished value is not.


The product is judged before it is used

The second bottleneck is the one technical teams still tend to underweight.

Even if you ship a good app, you still have to make it legible before anyone uses it. Modern products are interpreted through surfaces that come before onboarding:

  • screenshots
  • feeds
  • landing pages
  • explainer videos
  • clips
  • demos
  • app store assets
  • reviews
  • social proof

Calling these “marketing assets” understates their role. They are part of the product system because they determine whether the product earns attention and trust before onboarding begins.

When teams treat interpretation as downstream cleanup work, feedback gets slower. Screenshots, landing pages, and demos start drifting away from the objections real users actually have.

I have seen the same pattern in marketing systems and wrote about it in Why Marketing Velocity Slows When Execution Lives Outside the Team.

The bottleneck moved from production to interpretation.


Template work gets cheaper. Judgment work gets more valuable.

This needs nuance. Not every design role automatically becomes more valuable.

AI will keep getting better at:

  • generating variations
  • resizing assets
  • producing rough layouts
  • assembling predictable visual patterns
  • speeding up first-pass exploration

That part of design will get cheaper.

The higher-value work moves closer to judgment. The designers with the most leverage will not just move pixels well. They will:

  • think like product people
  • reduce ambiguity
  • improve comprehension
  • decide what friction is acceptable
  • connect interface quality to conversion, adoption, and trust
  • understand the story the product has to tell in the market

The leverage shifts away from pixel throughput and toward decision quality. That is the distinction that matters.


Design can no longer stay at the end

If software production is becoming abundant, design can no longer be treated as late-stage polish. It has to move closer to product shape, messaging, and distribution.

Founders should stop treating design as the part you add once the “real product” is done. Technical teams should stop assuming shipping code means shipping a finished product. Designers should move closer to product decisions instead of defining their role too narrowly around screens.

Teams in general should hire and structure around a more complete skillset:

  • product judgment
  • UX clarity
  • narrative discipline
  • visual communication
  • enough growth awareness to understand how the product earns attention

The premium capability is no longer just building fast. It is building fast while making sharp product decisions early.

When that discipline is missing, the cost rarely stays local to UX. It often turns into the same kind of unpaid tradeoff described in Most Technical Debt Is a Leadership Decision, Not an Engineering Accident.


Restraint compounds faster than output

This is not an argument that engineering matters less. It is an argument that software is no longer scarce in the way it used to be.

When production gets cheaper, abundance stops being impressive by itself.

For a long time, software rewarded the people who could make things. Increasingly, it rewards the people who can eliminate unnecessary things before they ever get made.

That is what this shift is really about.

The hard part is no longer generating more output. It is:

  • deciding what is worth making
  • shaping it into something people can understand quickly
  • making it feel coherent in use
  • giving it a narrative strong enough to compete for attention
  • refusing the extra features, flows, and claims that weaken the whole thing

In an abundant production environment, restraint compounds faster than output.

That is why design is moving closer to the center. Not because it is magical, but because the market is filling up with buildable things, and value is shifting toward the people who can decide which things should exist, what form they should take, and what should be left out.

The next scarce skill is not building.

It is designing what deserves to exist.

Share this article

Let’s Plan Your Next Project

If you’re building something fast, modern, and beautifully crafted — let’s talk. I help founders and teams turn ideas into polished, high-performance products.