An unfiltered reflection on what matters less, what matters more, and where an external studio will continue to create value.
Over the past twenty years, turning an idea into a digital product has been difficult enough to create an entire market around the people who knew how to do it.
It took different skills, time, coordination, and a significant amount of money. There was a substantial gap between an idea and something people could actually use, and much of the value lay in the ability to bridge it. Designers, developers, product managers, product marketers, user researchers, strategists. Companies built these teams internally and looked outside for the skills they lacked. Designing and building required people who were hard to find, which made them valuable.
In his article “We Built Companies Around the Cost of Building,” Geoff Teehan, Chief Design Officer at fintech company Lightspark, observes that development costs ultimately shaped not only product processes, but the very structure of companies. Teams researched and discussed, designed, and estimated time and costs. Only after passing through a series of filters did anything actually reach development. That system had plenty of limitations, but it also served a useful purpose: it prevented many ideas from becoming software.
This balance is changing very quickly. Artificial intelligence is lowering the cost of turning an idea into something tangible. A founder can independently build a first working version of a technology product; a product manager can test a proposition without waiting for an entire development cycle; a designer can easily move beyond a visual prototype; and a developer can delegate a significant portion of their work to agentic development tools.
This challenges one of the traditional reasons for turning to an agency or an external firm: gaining access to skills that were not available internally. No designers? We have them. No developers? We’ll build the product. Don’t know how to turn an idea into a prototype? That is exactly what we do. Building excellent products remains difficult. But hard skills alone are no longer enough to explain why a company should choose an external partner.
Meanwhile, the economic climate has grown more uncertain, and companies are choosing very carefully where to invest. The value of design and the cost of producing it, closely linked for years, are beginning to separate.
Knowing how to make things is no longer enough. We need to be much clearer about the value we bring. The question then becomes: if making gets easier, what remains difficult?
Where the value lies
As the number of possibilities grows, it becomes harder to understand which ones deserve attention. We can explore ten directions where we once explored two, or build in a few days a feature we will then have to maintain for five years.
An abundance of possibilities increases the need for judgment. This is where judgment and taste come into play.
Judgment is the ability to make a sound decision when there is no obviously correct answer. This is a normal condition in projects: incomplete information, business goals, user needs, technical constraints, and different opinions. At some point, you have to take a position. Experience helps with this too. It does not guarantee that you will be right—that would be too easy—but it helps you recognize certain patterns faster, understand where it is worth digging deeper, and notice when a seemingly secondary issue is actually shaping everything else.
Taste is something different. It is not only about aesthetics, but about the standard by which we judge a solution. It is the ability to recognize when something works but is not yet good enough, when we have added complexity instead of solving a problem, or when a formally correct solution still fails to convince. AI can multiply the alternatives, but it cannot remove the need to decide which ones are genuinely good and which are merely plausible.
Ed Landon, Design in the AI Age
If reaching something that works becomes easier, value shifts even further toward the ability to understand what is useful, relevant, and well made enough to deserve being chosen.
Taking a position
A client does not buy skills alone: they also place their trust in the judgment of the people they have chosen. Presenting five options and concluding that “it depends” is easy. What is harder is being able to say: we studied the problem, explored the alternatives, and this is the direction we recommend. It means putting yourself on the line, explaining the reasons behind a choice, and accepting the possibility of discovering that you were wrong.
If I can generate fifty versions of a homepage on my own, I probably have less need for someone to produce the fifty-first. I have a much greater need for someone I trust to tell me which forty-eight to discard and which one to actually pursue.
Returning to what matters
This change inevitably forces us to ask what it means for Moze. The more I think about it, the less I feel the need to invent a new identity to adapt to the moment. Instead, this change forces us to distinguish more clearly between what is essential to our work and what has simply accumulated around it over the years.
When we founded Moze in 2012 and in the years that followed, we talked about an Agile Studio. It was our way of describing a fairly simple approach: keeping design and development close together, moving in small steps, building early, and continuously testing our ideas.
Since then, the tools, the scale of the projects, and even the meaning of many of the words we used have changed. The principle, however, has remained remarkably stable: understand the problem well, look for the simplest possible solution, and bring it into the real world quickly enough to challenge it.
That is why I do not think Moze needs to add a new specialization to the list or chase a more contemporary definition of what a studio is. I would rather return with greater conviction to the reasons we chose to do this work in this way.
The context has changed a great deal. The starting point has not.
Thinking by making
Talking about judgment and the ability to choose might suggest a more consulting-oriented studio—one that builds less and spends more time telling others what they should do. That prospect does not interest us much.
Thinking and making are much harder to separate in our work than they might seem. As long as a solution remains in a conversation, a document, or an abstract prototype, it can survive for a long time without ever being truly tested. Once you start building it, constraints and contradictions emerge that you could not see before.
This is one of the reasons we have always tried to keep design and technology very close. A design decision changes when it meets the code; a technical decision changes when it meets the experience of the people who will use the product. The best solutions often emerge precisely there.
For this reason, I do not believe that making becomes less central. What changes is why it matters. If part of the execution can be delegated to machines, the value no longer lies in the time required to produce something, but in what we learn by building it and in the decisions that process allows us to make.
Removing to simplify
More and more often, a client sends us a prototype built with Claude. The first reaction is almost always the same: impressive. Within a few hours there is a working product, with screens, interactions, and details that until recently would have required days of work.
Then you start looking at it closely, and there is almost always too much in it. Features nobody asked for, options for unlikely scenarios, settings, filters, elaborate dashboards. Taken individually, many of these elements make perfect sense. Together, they become confusing, to the point where it is difficult to understand what the product actually is. This is not a flaw in Claude; it is a fairly natural consequence of tools that make it very easy to ask for more and much harder to entrust with deciding what is unnecessary.
This brings us back to something we have always considered central to the way we design: simplicity. For us, simplicity is mostly about removing things. Understanding what is truly necessary, eliminating a step, removing a pointless choice, and questioning a request before automatically turning it into a new feature.
Saying what we really think
Over the years, we have increasingly come to appreciate the ability to tell a client that, in our opinion, they should not do what they are asking us to do.
It happens more often than you might think. A request for a new feature comes in and, as we dig into the problem, we discover that it may not be needed. A request to design a mobile application turns into a simple newsletter. Other times, we realize there is no need for a redesign or a new platform, even though those would be very convenient things to sell.
These conversations sometimes cost us something in the short term. If the business model depends on the number of days you can put into an estimate, suggesting that the client do less is not exactly the smartest strategy for increasing revenue. And yet, that is often where the relationship is built.
When we work well with a client, at some point they stop calling because they need designers or developers. They call because they want to know what we think. That question only matters if they know we will tell them what we actually think, even when it means selling less work.
For us, honesty has always been much more tangible than a value written on a page. It means being able to say that an idea does not convince us, that the real problem may lie elsewhere, or that a path is needlessly complicated. Producing a prototype, an interface, or some code quickly will become increasingly easy. Finding people you trust enough to let them challenge you will remain much harder.
An external studio can bring something else as well: constant exposure to different companies and products. We will never know a client’s business as well as the people who work there every day, but we can recognize situations we have seen elsewhere, find analogies, and challenge habits that have become invisible from the inside.
What is time worth?
If the value changes, sooner or later the way we sell it must change too.
For years, we estimated projects by counting people and days. That made sense when the time required was a good approximation of the work involved: ten days of design and twenty days of development described the scale of a project fairly well.
If today we can solve in three days a problem that once took ten, the value produced does not automatically become one third of what it was. A good decision made during those three days can prevent months of unnecessary work. Selling time alone therefore creates a paradox: the more efficient we become, the less we should be worth.
Person-days will not disappear. But I believe the difference will become increasingly clear between those who mainly buy execution and compare it on price, and those who choose a studio for the way it approaches problems and the quality of the decisions it can help them make.
Perhaps there will be fewer clients. But they will choose you because they want to work specifically with you, not because you cost less than someone else.
Changing shape, not identity
Smaller teams will probably be able to do work that used to require many more people. Some skills will carry a different weight, services will change, and perhaps so will the markets in which we work. It doesn't make sense to defend a company's current structure as if it were part of its identity.
For Moze, this means being willing to change: roles, processes, business model, and even the kinds of problems we work on. What we do not want is to build a new identity for ourselves every time the market changes direction. Becoming an “AI agency” because that is what everyone is looking for today, or adding services simply because they seem easy to sell. Instead, this moment forces us to distinguish between what belonged to a particular market and what truly says who we are.
At the same time, it would be equally naive to behave as though nothing had changed. AI is not simply another tool to add to the toolbox, something we can dismiss by saying that we now do “AI-assisted” design and development with Gemini or Claude. It is changing the speed at which we can explore alternatives, the boundaries between different skills, and inevitably the way clients evaluate our work. This is a profound change, and pretending it is only about the tools would be a convenient way to avoid confronting it. That is why we are talking about it.
The point is not to preserve Moze exactly as it is today. It is to preserve what makes it recognizable while everything else changes.