Do you want to build an app in a weekend? Spin up a working prototype before the next stakeholder meeting? Generate ten feature concepts before lunch? If that sounded like science fiction few years ago, the tools now exist.
This core question stems directly from the theme of this year's How to Web Conference 2026: "What will you build when you can build anything?" that took place early October in Bucharest, Romania. Gathering over 3,000 tech leaders, founders, investors, and executives from Central and Eastern Europe and beyond, Europe’s leading startup and innovation event centered its agenda around navigating this exact shift: from visionary concepts down to real-world execution.
Because, the question that now presses hardest on founders, operators, and product teams is not whether they can build something, but whether they should, for whom, and whether anyone will actually use it.
The good judgment to choose the right problem
Bogdan Iordache, General Partner at Underline Ventures and founder of How to Web Conference, cuts straight through the optimism surrounding cheap, fast software: “You can indeed build any app in a weekend, but that’s not where value will be created.”
As simpler software becomes a commodity, he sees an opportunity in addressing more technically complex challenges. "The new generation of software will rely on agentic software patterns, task-specific models, and data loops, and will redo the software of today."
Iordache believes this new layer that will run on agentic software patterns will influence rebuilding of the software stack from the ground up, and the founders who treat it as such will hold an advantage that cannot be replicated over a weekend.
Nesrine Changuel, a product coach, author of Product Delight, and former product leader at Spotify, Google, and Skype — locates the real change is happening at the level of intent.
“When we can build almost anything, building becomes less of the problem. Choosing what deserves to exist becomes the problem.”
She argues that when building grows cheap and fast, the differentiator moves upstream: “It becomes less about can we build this? and more about: Should we build this? For whom? Why does it matter? What should the experience feel like? And what should we deliberately not build?” The products that stand out, in her view, will not be those with the longest list of AI-powered features. They will be the ones that create a meaningful connection with their users.
Crafting delightful and useful user experience
As any kind of digital project is just a prompt away, many end up with similar user interface and generic user experience. They might get the job done, but there always appears to be some kind of friction in the process. If this sounds familiar, it will become even more common as vibe-coded project flood the internet.
Crafting useful solution, meaningful user journey and delightful user experience will become one of the most important moats (although it should have always been). If there is an expert that can give us advice on this, its Changuel. During her talk at How to Web Conference 2026, she challenged teams to look past pure functionality and shared her exact framework for emotional product design.
Drawing on her time at Spotify, she makes a concrete point. Spotify Wrapped, she explains, “transformed behavioral data into something deeply personal. It did not just tell people what they had listened to. It gave them a story about themselves that they wanted to explore and share.” The technology mattered, but the deliberate choice about how that information should make people feel shaped the experience.
At Google, she worked on decisions that addressed “a much more human need: helping people feel comfortable, seen, or connected during video calls when technology mediated a fundamentally human interaction.”
On AI’s role in this, she draws a clear boundary: “AI can generate ten possible features. It can prototype them, write the code and even help test them. But it cannot automatically tell us which one will make our users feel understood.” To measure whether a product crosses that threshold, she developed the Delight Score, a framework that assesses emotional connection across three dimensions:
- whether a product addresses a real need,
- exceeds expectations in meaningful ways, and
- anticipates what users will need before they ask.
Not every project is worth it
Moving from product to economics design and strategy, Bogdan warns that everything you build comes with a cost, “and some things remain very expensive to build”.
What are the most critical assumptions a founder or any kind of organization should test with a live prototype before spending real capital or hiring a team to build it? On that note, we had opportunity to speak with another How To Web Conference speaker: Andrei Manea, founder and CEO of CloudHero, a Romanian cloud, data, and AI company named the 2024 AWS Global Application Modernization Partner of the Year. He operates in heavy legacy sectors like energy, telecom, and utilities – domains notoriously resistant to software adoption.
Manea believes when live prototypes can be deployed in hours, the goal is not to impress stakeholders with a flashy demo, but to test critical behavioral and economic assumptions immediately. He is engineer turned entrepreneur, but for him technology only matters when it delivers a measurable, operational result. So, his test for any prototype is behavioural, not technical: “I want to know whether someone will actually change how they work to use it.”
From demo to pilot
When Manea brings live, agent-built prototypes into early meetings with corporate customers, the effect is specific and limited. It’s not that prototypes are not useful, far from it: “They make people more willing to try a pilot. Seeing something work makes it easier to understand what they’re being asked to commit to,” but he is careful not to oversell it.
Also, procurement and security approval do not accelerate because a demo impressed someone. In regulated or traditional industries, the questions of what information a system can access and who is responsible for it still move at institutional speed. What the prototype does is give the meeting a concrete object — something to react to, refine, and attach a date to.
“The prototype helps us decide whether there’s enough promise to run a pilot. The pilot is where we measure what happens when people use it in their normal work.”
Execution risk doesn’t go away with the first working version. That is the time where you can find out whether you are solving the right problem, Manea explains. However, during that early stage it is also important to align what result would make it worth paying for before you build it. Here are some neccessary steps Manea recommends to take before committing either money or team over a vibe-coded demo:
- Put the live prototype into the user’s hands with their actual data for a task they must complete this week. Stop presenting and watch where they struggle or rewrite generated outputs.
- In any orgs operations saving ten minutes for an operator is meaningless if it creates twenty minutes of clarification work for their supervisor. Success must be measured across the entire operational chain.
- Before writing production code or hiring a team, establish what result would justify paying for the solution. Compare the high-tech solution to simpler process interventions (like a better structured form) and factor in long-term support and integration costs.
This is opportunity to do better
Taken together, these three perspectives converge on a single reorientation. Speed and capability have stopped being the bottleneck. What founders and product teams now need to develop, and what no AI tool supplies automaticallym, is the judgment to choose the right problem, the discipline to test whether real behaviour changes, and the intent to build something users will miss when it is gone.
The opportunity that cheap, fast development opens is not to ship more, but to to finally build better products.
Member discussion