Here’s what happens when businesses skip the definition step – and how to avoid it.

When “AI” means everything, it means nothing

The term “AI” currently covers an enormous range of technologies – rule-based automation, recommendation engines, machine learning models, large language models like GPT-5.5, and fully autonomous AI agents. These are fundamentally different things with different costs, capabilities, and failure modes. Yet they all get called “AI” in boardrooms and budget meetings.

Think of it like calling everything with an engine a “vehicle.” Technically correct, but not helpful when you’re trying to decide whether you need a forklift or a company car.

In practice, this vagueness creates three concrete problems for anyone trying to make decisions:

• For buyers/clients, it makes vendor evaluation nearly impossible – you can’t compare solutions if you don’t know what problem you’re solving
• For internal teams, it creates confusion about what’s expected and how success will be measured
• For compliance, it makes it nearly impossible to assess risk, accountability, or regulatory fit

In Switzerland specifically, where compliance expectations are high and SMEs operate under tight regulatory scrutiny, “we’re implementing AI” is not an adequate answer to auditors, data protection officers, or procurement reviewers. Definitional vagueness isn’t academic – it creates real legal and financial exposure.

When a new client says “we need AI,” our team at what. always asks the same set of clarifying questions before anything else:

• What specific task or decision are you trying to improve or automate?
• Where exactly does the current process break down or slow down?
• Does this require judgment and adaptability, or is it a predictable, rule-based task?
• How will you measure whether it’s working?
• Who owns the outcome if it goes wrong?

These aren’t gatekeeping questions. They’re the foundation of any project that actually ships.

Why vague AI goals sink projects before they start

Companies often adopt AI because it feels urgent – competitors are “doing AI,” leadership is asking about it, and nobody wants to be left behind. That’s understandable. But adopting AI because it’s fashionable, rather than because you’ve identified a specific problem it solves, is how budgets disappear with nothing to show for them.

Without a clear definition of what the AI is supposed to do, three things become genuinely impossible:

This connects directly to something we’ve written about before: the “garbage in, garbage out” principle. As we explored in Before You Touch AI, Fix Your Workflows First, AI built on broken or undefined processes doesn’t fix those processes – it just makes the confusion run faster.

What a useful AI definition looks like

Instead of arguing about what AI “is” in the abstract, the more productive question is: what does it need to do for your business, and does it actually require AI to do it?

Before starting any AI project, work through this checklist:

• What specific task should this system perform? (One task, defined precisely)
• Does it need to learn, adapt, or handle ambiguous inputs – or would a simpler rule-based automation do the job just as well?
• How much human oversight is needed, and at what points?
• How will success be measured, and within what timeframe?
• Is this meaningfully different from standard automation?

That last question is the most important one. If the honest answer is “not really” – that’s not a failure. It’s a signal to use the simpler, cheaper, more reliable tool.

This matters especially in the Swiss context. Labour costs here are among the highest in the world. Every poorly-scoped AI project is expensive twice over: once in direct spend, and once in the staff hours lost to a tool that doesn’t work properly. Being precise upfront is not over-engineering – it’s basic financial discipline.

It’s also worth noting that many problems framed as AI problems are actually integration problems. When a client tells us their team is spending hours manually reconciling data between their CRM, ERP, and accounting system, they often assume they need AI to fix it. Usually, they don’t. They need their systems to talk to each other. Our tools integration work resolves the majority of these situations without any AI model involved – and does it faster and more reliably.

What our AI automation expert says

What our AI automation expert says

Most clients don’t have an AI problem – they have a clarity problem. Once we define the actual task, the right solution usually becomes clear, and it’s often simpler than they expected.

Sergei Gordeichuk

Head of Technology at what.

Define first, build second

The companies getting real results from AI aren’t necessarily the ones moving fastest. They’re the ones who were clearest about the problem they were solving before they committed to a solution.

A precise brief – one that defines the task, the success criteria, the data requirements, and the governance expectations – is worth more than any tool. AI automation becomes genuinely powerful once that foundation is in place. Not hype, not a demo that gets shelved after a month. Real leverage, applied to a well-understood problem.

If you’re unsure whether what you’re looking at is an AI problem, an automation problem, or an integration problem, that’s exactly the right question to explore before spending anything. Get in touch with our AI automation team – we’ll help you find the honest answer.

The post Pushing AI Without Definition: Why It Backfires appeared first on what. AG.

Ask AI about your company’s current pricing policy and it might cite a version from two years ago. Ask it for a case study with real ROI numbers and it might generate one that sounds plausible but never actually happened. This is called a hallucination – or drift when the pattern keeps repeating.

Why does it happen? The model was trained on data that existed before your question. It doesn’t have access to what you’ve written internally, updated recently, or stored in your systems – and while some models can query the web to fill gaps, that’s neither reliable nor efficient for company-specific knowledge. So it fills the gaps with the most statistically likely answer, which isn’t always the correct one.

RAG – short for Retrieval-Augmented Generation – is the most practical solution to this problem. Instead of relying on the model’s memory, RAG connects it to your actual knowledge base in real time. Company policies, sales documents, internal manuals, FAQs – when someone asks a question, the system first finds the relevant passages from your content, adds them as context, and only then generates an answer based on that material.

It’s genuinely powerful. Your internal documentation can become something like an operational oracle, answerable in plain language. But it’s not magic, and it’s not the right tool for every situation.

By the end of this article, you’ll know what RAG actually does, how to prepare your content for it, and when it’s the right choice versus when you need something more structured.

How RAG works (without the jargon)

RAG sits invisibly between your question and the AI’s answer. The model doesn’t answer from memory alone; it first retrieves relevant material from your knowledge base and uses that as the foundation for its response.

Here’s the process, stripped down:

1. Content preparation: You load your documents (policies, FAQs, procedures) into the system in a structured, readable format.
2. Indexing: The system processes that content using two complementary approaches: classic keyword search and semantic search (more on this below).
3. Retrieval: When a question comes in, the index pulls the most relevant passages.
4. Generation: The AI produces an answer using those retrieved passages plus its general knowledge.

The result is an answer grounded in your actual content, not generated from scratch.

Why hybrid search matters

Keyword search works well when someone uses the exact term that appears in a document. Semantic search goes further: it understands meaning, not just words.

For example: “how to increase company margin” and “reduce operating expenses” point to the same concept but share almost no keywords. Semantic search finds relevant content even when the phrasing is different. In practice, well-built RAG systems use both approaches together. Keywords catch precise references, product codes, and proper names. Semantic search handles everything where intent matters more than exact wording.

RAG vs. fine-tuning

These two are often confused. RAG doesn’t change the model itself – it uses a ready-made LLM (like Claude or GPT) and passes it the right slices of your knowledge base on each question. Update the knowledge base and re-index it, and answers stay current.

Fine-tuning is different. It permanently adjusts how the model behaves or speaks. That’s useful when you need a consistent style or domain-specific behavior – not when you mainly need accurate, up-to-date answers from documents.

One important thing to keep in mind: RAG is only as good as its retrieval. Wrong context in means a confident but wrong answer out. More retrieved content also means more tokens processed, which adds cost. That balance is something you design deliberately; it’s not a case of “more documents equals better answers.”

At what., we don’t always build RAG from scratch. We choose the approach that fits the actual need – custom RAG, managed search solutions, or a combination – so you’re investing where it genuinely pays off.

Read also: Why do you need AI to automate your processes in the first place?

Preparing your AI knowledge base: why format matters more than you think

RAG retrieves what you wrote. If your documents are messy, fragmented, or poorly structured, the system won’t magically understand your business – it’ll find weak chunks and the model will fill the gaps with confidence. That’s when hallucinations sneak back in.

Retrieval quality depends almost as much on your content as on the algorithm behind it.

Markdown vs. PDF

PDFs are great for reading and sharing. For RAG, they’re often a headache. Complex layouts, broken tables, scanned pages – all of that needs OCR or a parsing step before it can be indexed. That adds cost, processing time, and a real risk of garbled text ending up in your knowledge base. Tools like LlamaIndex are widely used to handle this when PDF is unavoidable, but it’s always more effort than clean structured text.

Markdown works better because structure is explicit: headings, sections, and lists tell the indexing system exactly where one topic ends and another begins. For an AI model trying to retrieve the right chunk, that clarity makes a significant difference.

Markdown is also format-agnostic. It converts cleanly to HTML, Word, PDF, and most CMS exports, so your RAG pipeline isn’t locked to a specific vendor or tool. And it’s been the standard in software documentation for years precisely because it’s plain text, version-control friendly, and easy to maintain.

The practical rule: keep PDFs for archiving and distribution. Use Markdown (or equivalent structured text) as the working format for everything that goes into RAG. If you only have scanned PDFs, budget for extraction – it’s doable, but it costs more and introduces more room for error.

How to structure your documents for retrieval

A few simple habits make a meaningful difference in how well RAG performs:

• One topic per section. Use clear headings. Avoid single massive files that cover everything – prefer themed documents or well-separated sections so retrieval returns coherent blocks rather than half a chapter mixed with unrelated content.

• Descriptive, specific titles. “Introduction” or “Appendix” don’t help search. “Remote work policy – Switzerland” or “Handling price objections – enterprise clients” does. The title is often what gets matched first.

• Put codes and references early. If you use internal procedure codes, module names, or SKUs, include them in the heading or the first line. That makes keyword search hit the right place immediately.

• Use numbered lists for processes. Step-by-step procedures retrieve and cite better than dense prose paragraphs. If there’s a sequence, format it as a sequence.

• Cut the noise. Repeated headers and footers, legal disclaimers on every page, duplicate versions of the same document – all of this pollutes your index. Clean content retrieves cleanly.

A note on chunking

Long documents get split into smaller chunks for indexing. Chunks that are too large bring in too much noise; chunks that are too small lose the thread of meaning. Splitting at Markdown headings naturally keeps related content together and reduces the risk of cutting a concept in half.

Good indexing pipelines also use overlap – a few lines from adjacent sections are included with each chunk so the model doesn’t lose context at the boundary. If a document is short and always relevant in a given flow, sometimes including it in full works better than relying on retrieved fragments alone.

The honest question to ask before buying a more expensive model or platform: is your knowledge base actually findable? A well-designed RAG on clean content will consistently outperform a mediocre setup on chaotic PDFs, at the same API cost.

Not everything belongs in RAG the same way

It’s worth being deliberate about what goes where. Three categories are useful:

A common mistake is putting critical step-by-step procedures into RAG and hoping the model will follow them in order. It won’t reliably. Retrieval finds relevant fragments – it doesn’t replace a workflow engine with enforced sequencing.

Read also: Before implementing AI, it’s worth making sure your underlying workflows are solid first.

When RAG is enough – and when you need more

This is the question that saves teams from overbuilding or underbuilding.

RAG paired with an LLM is the right setup when someone asks a question and needs a grounded answer. It’s not the right setup when the interaction requires a process with mandatory steps, tracked state across sessions, or sequenced decisions that can’t be skipped.

Two mental models:

Quick rule of thumb: one question, one answer, no mandatory sequence across sessions – start with RAG and an LLM. Same user, multiple turns, steps that can’t be skipped – add orchestration. RAG then serves as the supporting library, not the backbone of the process.

Three cases where RAG + LLM is the right call

• Internal FAQ or HR policy. “What’s our remote work policy for employees based in Switzerland?” – A well-indexed corpus, an answer grounded in the actual policy document, no multi-step journey required. Find it, explain it, done.

• Sales enablement. “Do we have a logistics case study with ROI?” – A library of commercial documents that users explore based on intent, not a fixed script. RAG handles this naturally.

• Product support (L1). “How do I reset the connection on device X?” – One question, one answer, tied directly to the manual. If retrieval misses, fix the document, not the whole architecture.

Three cases where you need a stronger architecture

• Digital coaching or consulting with a playbook. Multi-week engagements where you’re tracking goals, working through options, and closing with a plan. The current step and session rules need to live outside the model – in a database or state machine. RAG brings in frameworks and examples when that step calls for them. Without orchestration, the AI skips phases or forgets what was agreed two sessions ago.

• Employee or partner onboarding. Week one: documents. Week two: training. Week three: competency check. That order might be contractual or compliance-driven. Finding the right PDF isn’t sufficient – you can’t open module three until module two is complete. RAG supplies the content; a state machine drives the path.

• Guided sales discovery. Qualification, then needs analysis, then proposal – with mandatory questions at each stage. RAG retrieves pricing, battle cards, and objection handlers. An orchestrator enforces the sequence: “no pricing discussion before the needs are declared.” Without that, AI quotes too early or invents a framework that isn’t yours.

Fix your content before you blame the model

The temptation when RAG underperforms is to upgrade the model or switch to a more expensive platform. Usually, that’s the wrong move.

Most retrieval problems trace back to content quality, not model capability. Documents that are too long, poorly titled, or duplicated across versions will confuse even the best retrieval system. The fix is editorial, not architectural.

Before investing in infrastructure, check three things:

1. Is the content ready? Structured, owned, up to date – not a mix of scattered PDFs and six versions of the same policy document.
2. Is this a search-and-answer problem or a follow-a-path problem? FAQs and policies usually need RAG + LLM. Playbooks and multi-step onboarding need orchestration too.
3. Is success clearly defined? “Useful answers tied to sources” is a success criterion. “It sounds smart” isn’t.

A fast way to find out where the real bottleneck is: pick one domain, curate 20 to 30 documents, write down 10 real questions your team actually asks. Run it. Within a few days you’ll know whether the problem is retrieval, content quality, or architecture – and you’ll have spent almost nothing to find out.

Want AI workflows that are reliable from end to end, not just at the retrieval step? Our tools integration services help connect the systems your RAG pipeline depends on – so data flows cleanly into your knowledge base and stays current without manual effort.

Ready to build a knowledge base that actually works?

The right question isn’t “which AI platform should I buy?” It’s “do I have a knowledge base worth retrieving – and a process that knows when to rely on RAG and when not to?”

That’s exactly the kind of question we help teams work through. As an AI automation agency, what. works with businesses to design RAG setups that fit the actual use case – not more complex than needed, not underpowered for the job. Whether that means a lightweight RAG-only setup or a fully orchestrated AI workflow, we help you figure out the right depth before you build anything.

Get in touch for a focused conversation. No sales pitch – just an honest look at whether RAG is the right fit and what it would take to make it work well.

The post RAG Explained: How to Give AI Your Knowledge Base appeared first on what. AG.

Understanding this shift matters for anyone building in or navigating the Web3 space today.

From monolithic chains to modular infrastructure

Early blockchains were built to do everything in one place. A single network handled transaction execution, reached consensus, ensured data availability, and provided settlement finality. Bitcoin and early Ethereum are the clearest examples: unified systems where every node participates in every function.

The problem with this approach is scalability. When one chain must do everything, it hits limits quickly. Higher demand means higher fees, slower transactions, and pressure to make trade-offs between decentralization and performance.

The modular approach breaks these responsibilities apart. Execution, settlement, consensus, and data availability each become distinct layers that can be optimized independently. A rollup, for instance, handles execution off the main chain and posts transaction data to a separate data availability layer like Celestia or EigenDA, while settling on Ethereum. Each component does one job well instead of one system doing everything adequately.

This architectural shift mirrors what happened in software engineering more broadly – the move from monolithic applications to microservices. The logic is the same: specialization enables scale.

For builders and innovators in the crypto space, this modular foundation has opened up new possibilities. Developers can now launch application-specific chains without building validator infrastructure from scratch, plug into shared security layers, and choose data availability solutions that fit their needs and budget.

The stack is expanding beyond blockchain scaling

Here’s where things get genuinely interesting. The modular blockchain stack started as a solution to a scaling problem. But it’s increasingly becoming something else: infrastructure for autonomous AI agents to communicate, transact, and coordinate.

This might sound like a stretch, but the logic follows naturally. AI agents – software systems that can take actions, make decisions, and interact with external services on a user’s behalf – are becoming more capable and more autonomous. As they start participating in real economic activity, they need reliable infrastructure underneath them. They need to prove who authorized them, make payments, verify the trustworthiness of other agents, and leave auditable records of what they’ve done.

Blockchain’s core properties – transparent records, programmable rules, portable identity, and tamper-resistant logs – map almost perfectly onto what agentic AI requires. The stack isn’t replacing AI; it’s providing the trust and accountability rails that make autonomous agent activity safe and verifiable.

The convergence of agentic AI and decentralized infrastructure isn’t a future scenario – it’s already shaping how we think about Web3 architecture today. The projects that will define the next phase aren’t just building on blockchain; they’re building the coordination layer that lets autonomous systems act with trust, accountability, and economic purpose.

Liwaa Chehayeb

Head of Web3 at what.

Read also: the ongoing tokenization era points to a parallel shift — blockchain is moving from purely speculative infrastructure toward systems that support real economic value. Agentic AI is accelerating that same trajectory.

The protocols shaping the agentic Web3 stack

Several emerging protocols and standards are extending the modular stack specifically to support AI agent activity. Together, they form something that could reasonably be called an agentic commerce infrastructure.

Agent Communication: A2A

A2A (Agent-to-Agent protocol) addresses how AI agents communicate with each other. The future of agentic AI isn’t one all-knowing agent doing everything. It’s a network of specialized agents, each handling a particular domain. 

One agent handles research, another handles payments, another handles compliance checks. A2A provides the common language these agents use to coordinate and delegate tasks between each other.

Tool Access: MCP

MCP (Model Context Protocol) handles tool access. It allows agents to connect with external systems – databases, APIs, blockchain explorers, business workflows, payment services. 

Without MCP, an agent is essentially isolated. With it, an agent can actually interact with the digital world: checking a transaction on-chain, retrieving a document, calling a pricing API, or triggering a business process.

Payment Authorization: AP2

AP2 (Agent Payments Protocol) focuses specifically on authorization. When an AI agent makes a payment on a user’s behalf, a critical question arises: was this actually authorized? AP2 is designed to answer that. 

It’s less about the mechanics of moving money and more about consent, permission scopes, and accountability. Think of it as the authorization layer that sits above the actual payment.

Payment Execution: x402

x402 handles the payment execution side. It revives the old HTTP 402 “Payment Required” status code and turns it into a workable standard for internet-native micropayments. 

An agent can pay for a premium data request, an API call, or even compensate another agent for completing a subtask – all automatically, without human involvement at each step. AP2 proves the agent was authorized; x402 handles the actual transaction flow.

Agent Identity and Reputation: ERC-8004

ERC-8004 tackles agent identity and reputation. As agents increasingly interact with other agents outside their own platform or organization, they need a way to evaluate trustworthiness.

Who built this agent? Has it successfully completed tasks before? Can its claims be verified? ERC-8004 aims to create an open reputation layer for agent-to-agent interactions – essentially helping agents decide who’s worth trusting and paying.

Smart wallets, spending limits, and constrained autonomy

One of the most important design questions in agentic AI is simple: how much financial autonomy should an agent have?

The answer should be: constrained. Not unlimited access to a wallet, but programmable, policy-bound access. Smart wallets and account abstraction make this possible. A user or business can configure an agent to spend only up to a certain amount per day, transact only with approved counterparties, request human approval above a certain threshold, or avoid specific transaction types entirely. Every action gets logged for review.

This matters because the goal isn’t maximum autonomy – it’s useful autonomy within clear guardrails. An AI travel agent that books the cheapest flight within your budget is helpful. An AI agent with unconstrained access to your funds is a liability.

Cross-chain coordination and the UX opportunity

AI agents won’t care which blockchain a service runs on. They’ll care whether the task can be completed quickly, cheaply, and safely. This makes interoperability a first-order concern for the agentic Web3 stack.

An agent might need to pay on one network, verify data on another, and use a service that settles on a third. Cross-chain infrastructure that handles this routing invisibly – without requiring the agent (or the user) to manually manage bridges and gas tokens – is essential for this vision to work in practice.

This connects to one of Web3’s persistent challenges: user experience. Managing wallets, private keys, gas fees, and cross-chain transfers has kept most people at arm’s length from blockchain-based services. AI agents could absorb all of that complexity. Instead of a user interacting directly with decentralized infrastructure, the agent handles it – and the user simply receives results.

That’s a genuinely compelling proposition for broader Web3 adoption. The next major interface for Web3 might not be a wallet or a dApp. It might be an AI agent. Projects like the DMCC crypto and AI ecosystem are already building regulatory and commercial frameworks that anticipate exactly this kind of convergence.

Trust, accountability, and the risks that remain

Autonomous agents create real trust challenges. They act faster than humans can supervise, may interact with unknown services, and can spend real money. Mistakes are possible. So is manipulation – fake or low-quality agents gaming reputation systems, compromised wallets, or insecure API connections.

Blockchain helps address parts of this problem. Transparent execution records, smart contract-enforced rules, verifiable identity, and auditable transaction histories all reduce the risk surface. But blockchain isn’t the brain of an AI agent. It’s the accountability layer around it. The agent decides and acts; the blockchain ensures those actions are recorded, authorized, and traceable.

The honest framing here is that agentic AI and Web3 integration is still early. Standards are fragmented, liability questions are unresolved, and regulatory frameworks haven’t caught up. As with tokenization’s positioning problem, the technology is often ahead of the governance and communication structures needed to make it work in practice. The goal should be constrained autonomy – agents that can act effectively within well-defined rules, budgets, and accountability frameworks, not agents operating without meaningful oversight.

A real-world agentic workflow: what this looks like in practice

Abstract protocol names are one thing. But how does the full agentic Web3 stack actually behave in a real scenario? Here’s a concrete example.

Say a logistics company wants to automate vendor procurement. They configure an AI agent with a clear mandate: source a certified freight partner for a shipment from Dubai to Rotterdam, negotiate within a predefined budget, and complete the booking – all without manual intervention.

Here’s what happens under the hood:

• The user defines the task and sets parameters inside a smart wallet: maximum spend of $8,000, approved vendor categories only, human sign-off required above $10,000. The agent gets to work.

• Using MCP, it connects to freight databases, logistics APIs, and compliance registries to pull live rates, carrier certifications, and regulatory requirements for the route.

• It needs help assessing carbon offset compliance for the EU leg. So via A2A, it delegates that subtask to a specialized compliance agent. That agent checks relevant registries, confirms compliance status, and reports back.

• Before committing to a vendor, the agent checks the carrier’s ERC-8004 reputation profile. The carrier has completed 400+ verified cross-border bookings, holds a strong on-chain track record, and has no dispute history. Trustworthy enough to proceed.

• The carrier’s API responds with an x402 payment request for the booking deposit. The agent checks back with AP2 to verify the payment is within authorized parameters. It is.

• The smart wallet validates the spend against the user’s policy rules and executes the transaction. The booking is confirmed, the transaction is logged on-chain, and a full audit trail is created automatically.

• The user gets a notification. Total time: minutes. Manual steps required: zero.

For businesses exploring how AI automation can power these kinds of workflows, the underlying principles align closely with what our AI automation services team builds for clients today. The difference is that Web3 infrastructure adds the trust, payment, and identity layers that make those workflows verifiable and economically sovereign.

Also worth reading: 2026 Will Be the Year of Autonomous Workflows explores how AI-driven automation is reshaping business operations more broadly.

What to watch as the agentic stack matures

The protocols and standards discussed here are still developing, but several trends are worth tracking closely:

• Adoption of x402 for API-level micropayments and agent-to-agent compensation
• AP2 becoming a standard for verifiable agent payment authorization in enterprise contexts
• ERC-8004 development as a trust and reputation layer for cross-platform agent interactions
• Smart wallet infrastructure maturing to support complex, multi-agent spending policies
• Stablecoin micropayments enabling machine-to-machine transactions at scale
• Agent marketplaces where specialized AI agents offer services to other agents or users

Each of these represents a piece of the broader picture: a Web3 infrastructure that was built to scale blockchains, now evolving to coordinate autonomous digital activity across networks, agents, and economic systems.

The modular blockchain stack isn’t just a better way to build blockchains. It’s becoming the coordination and trust layer for the next generation of the internet – one where AI agents are active economic participants, not just tools that answer questions.

If you’re building in this space or thinking about how agentic AI and decentralized infrastructure intersect with your business, our team at what. works with crypto and Web3 projects at exactly this frontier. Explore our Web3 & Crypto services to see how we can help you navigate and build in this evolving landscape.

The post How Modular Blockchain Powers Agentic AI and Web3 appeared first on what. AG.

Metro Boutique and the honest numbers behind the migration decision

Metro Boutique runs 25 stores across Switzerland and speaks to a crowd between 16 and 34. The online store worked – but that was about it.

The NopCommerce system from 2015 was costing CHF 250,000 a year in maintenance alone. Every content change needed a developer. Black Friday campaigns had to be manually switched on at midnight. Scheduling simply didn’t exist.

The main driver was financial: platform costs were making it harder and harder to stay profitable.

Phase 0: Business case first, migration second

what. didn’t kick things off with development. Instead, we started with a structured Store Check & Migration Assessment – the goal being to figure out, based on actual data, whether a Shopify migration even made sense, and if so, how to approach it.

The assessment came back with concrete numbers:

• 55% TCO savings over 5 years
• CHF 2 million in projected savings over the same period
• 9 million URLs in the existing store – only 88,000 of which were indexed
• 1.04% conversion rate as a starting point

That’s a business case you can actually defend internally. Management could back the decision with real numbers, not just gut instinct.

One more insight from the assessment: Metro Boutique’s strong brand identity lived primarily in its physical stores. Online, it felt muted. “Same brand, different decibels.”

The system landscape before and after the migration

The three biggest technical challenges – and how what. solved them

Complex system landscapes always have spots that look straightforward on paper but aren’t in practice. At Metro Boutique, there were three of them.

Akeneo Connector

The existing Akeneo connector wasn’t up to the task for Metro Boutique’s specific data structure. The vendor was slow to respond and not particularly open to making adjustments. So what. built their own – clean, maintainable, and tailored to what was actually needed.

This comes up more often than you’d think. Off-the-shelf solutions rarely fit 100%. The difference is whether you’re willing to do something about it.

Physical Gift Cards as a Payment Method

Gift cards account for around 4% of online revenue. Shopify’s native gift card system isn’t built for physical in-store cards.

what. built a fully custom payment method that validates card balances via the external payment provider MF Group. It might sound like a minor detail – but letting 4% of revenue disappear simply wasn’t an option.

Worth noting: the old store already had this feature. The custom development simply closed the gap on the Shopify side.

App Wishlist Synchronization

The third-party solution originally evaluated caused synchronization issues. what. is currently developing their own script. This one is still in progress – and we’re being upfront about that here, because it’s part of the honest project picture.

Timeline: from proposal to go-live

The planned launch was October 2025. Actual go-live: mid-January 2026 – around 7 months after the project kicked off.

At go-live, there was no downtime, no data loss, and all critical integrations worked without a hitch.

The timeline shifted because integration quality took priority. That was the right call – going live with unresolved critical issues creates more problems than it solves.

What’s changed since launch

Denis Spycher from Metro Boutique puts it well:

“Internally, we’d been thinking about switching our shop system for a while – mainly because of high fixed costs and limited flexibility. From day one, I had a really good feeling about it. The collaboration was efficient, goal-oriented, and genuinely enjoyable. With Shopify, we now have significantly more flexibility, better efficiency in day-to-day operations, and a CMS that’s fast, intuitive, and easy to use.”

The conversion rate climbed from 1.04% to 1.08% in the first 90 days. That might sound small, but at the volume of a national fashion retailer, it adds up.

The qualitative changes are just as significant:

• The e-commerce team can now launch campaigns independently – no developers needed
• 95% of content changes are handled in-house
• Time-controlled campaign scheduling without manual activation is now possible (still to be implemented)
• The foundation for personalization, A/B testing, and SEO optimization is in place
• UX/UI improved
• Cost structure sustainably improved

And when it comes to day-to-day life for the team:

“Since going live, we’ve had a lot more freedom and can act much more proactively. For many things, we no longer need external support – we can step in ourselves, optimize the store, and test new ideas quickly. I’m convinced that Shopify Plus was the right decision for us.”

Platform costs are now around a quarter of what they used to be.

The complete technology stack

*The old store already had this feature; our custom development simply closed the gap on the Shopify side.

What this project says about the right migration approach

Shopify migration projects often don’t fail because of the technology. They fail because implementation starts too early, before anyone really understands the business case.

The assessment phase wasn’t a nice extra – it was the foundation that allowed Metro Boutique to make the decision and defend it internally. Understand first, decide next, then build.

And if an existing vendor connector doesn’t cut it, what. simply builds their own. That’s not a special case – it’s a principle. Complex system landscapes need solutions that actually fit.

Planning a similar migration?

If your platform costs are too high, your team depends on developers for every little change, or you just know your system is holding you back – the first step is an honest look at where things stand.

That’s exactly what our Shopify Migration Services are for: from the initial assessment through technical implementation to go-live and beyond. As Switzerland’s leading Shopify Plus agency with over 200 completed stores, we know where the real challenges tend to hide – and how to tackle them.

The post From NopCommerce to Shopify Plus: How what. Led Metro Boutique into the E-Commerce Future appeared first on what. AG.

How AI writing boosts your visibility

Traditional SEO focuses on keywords and rankings, but today’s algorithms need more. AI writing means crafting content that specifically helps artificial intelligence systems read, classify, and recommend your pages.

By structuring information clearly, adding metadata, and maintaining a logical flow, you make it easier for AI to understand your intent. This approach improves how your content appears across AI-powered search and voice platforms.

How to use this AIO checklist

No matter if you relaunch your website or need to boost your online store, follow these AI optimization and AI writing guidelines to maximise consistency and impact.

• Use Q&A Format
• Add Quotes
• Use Bulleted Lists
• Write Clear Headings
• Use Clear Metadata
• Include TL;DR / Summary boxes or key points
• Use Short Paragraphs
• Avoid Keyword Stuffing
• Link Internally
• Show Author Info
• Implement Schema.org
• Check Crawl Access
• Avoid Blocking LLM Bots
• Submit Sitemaps

AI writing & artificial intelligence optimization – best practices

To maximise visibility, AI writing should follow both linguistic and technical best practices.

Technical recommendations

The following practices ensure that AI systems can efficiently crawl, interpret, and represent your content across search, social, and emerging AI platforms.

Visibility across channels

Omnichannel optimization ensures your content performs across all touchpoints: search, social, video, and voice. The 4P framework – Presence, Performance, Personalization, and Persistence – defines how AI optimization extends your brand reach.

• Presence: Optimise keywords and metadata for discovery
• Performance: Track visibility metrics across platforms
• Personalisation: Adjust content tone and visuals per audience
• Persistence: Refresh and re-optimise content regularly

Google AI Overview

AI overviews present curated, high-authority answers at the top of search results. Being featured here places your brand in front of users during their research and discovery phases. This early exposure builds awareness, trust, and increases the likelihood of conversion later.

Related: Want to understand how AI overviews are changing search behaviour and what zero-click search means for your brand? Read our guide on AI Overview Optimization and Zero-Click Search.

AI content optimization guidelines

To make the most of AI optimization, your content should be designed not just for search engines, but for AI systems that interpret and distribute it across multiple channels. Start by focusing on user intent rather than obsessing over keyword density.

To maximise the effectiveness of AI writing and AI optimization, your content must deliver real value and avoid fluff. Thin, vague, or overly promotional content is often overlooked by AI systems. Focus instead on specificity, clarity, and user outcomes, and prioritise genuine expertise by including:

• Unique insights based on experience or research
• Practical advice users can apply immediately
• Proprietary frameworks or firsthand examples

Structure content around user-intent-driven questions using an FAQ or Q&A format. Headings should mimic natural search phrasing, for example: “How does AIO affect SEO strategy?” Provide clear, concise answers to each question.

Break down complex ideas using structured lists for steps, benefits, features, or comparisons. This helps both readers and AI models scan content efficiently. Use natural language headings rather than abstract or technical terms:

✔ What is the difference between AEO and GEO? 

✘ Comparative AI Optimisation Frameworks

Maintain consistent H2 and H3 formatting for readability. Routinely refresh and reuse content by updating outdated information, adding new answers to reflect evolving search behaviour, and consolidating thin posts into comprehensive evergreen pages. Don’t forget to incorporate short, attributed quotes from trusted sources or experts near key claims to reinforce credibility.

Related: New to AIO and GEO? Get up to speed on what these terms actually mean and why they matter in our article From SEO to AI Search.

Structured data guidelines

Structured data allows AI systems to interpret and display your content accurately in rich results. Proper markup enhances search visibility and click-through rates, which improves how search engines perceive your authority. Use Google’s Rich Results Testing Tool and Schema.org to validate markup. Keep schemas accurate and consistent with page content.

External citations guidelines

External links signal credibility to both users and AI systems. References strengthen trust and contextual relevance.

• Link to authoritative, high-domain sources (e.g., .edu, .gov, leading publications).
• Use contextual anchor text that clarifies relevance.
• Update or remove broken links periodically.
• Combine internal and external linking to balance authority flow.

Wikipedia serves as a key reference point for many LLMs and is used by generative AI search tools such as ChatGPT, Gemini, and Perplexity. Research shows that nearly 10% of all citations used by these AI systems originate from Wikipedia, which makes it among the most commonly referenced sources, alongside platforms such as Reddit and YouTube.

GEO and AI writing – how they work together

AI writing and GEO (Generative Engine Optimization) aren’t separate disciplines – they’re two sides of the same coin. Good AI writing gives AI systems the raw material they need. GEO ensures that material actually gets surfaced in the right places.

When your content is well-structured, semantically clear, and technically accessible, you’re not just helping a search engine crawl your page – you’re giving AI engines like ChatGPT, Perplexity, and Google AI Overviews the signals they need to include your brand in generated answers.

That’s why the practices outlined in this guide directly support a broader GEO strategy. Clean formatting, schema markup, and natural Q&A structure are all things AI engines rely on when deciding whose content to cite.

Future-proof your visibility with what.

AI writing and AI optimization form the future of digital growth. With structured, omnichannel content strategies today, your visibility remains resilient against algorithmic shifts. As a leading GEO and growth hacking digital agency, what. future-proofs your brand by leveraging AI-optimized and GEO strategies that drive visibility, relevance, and measurable results.

Want to know where your brand actually shows up in AI-generated answers – and where it doesn’t? That’s exactly what our GEO service is built for. We track your AI visibility, identify the gaps, and optimize your presence across ChatGPT, Perplexity, Google AI Overviews, and beyond.

Reach out to discover your AI writing and optimization approach: Book your free consultation with what.

The post AI Writing & AI Optimization – Guidelines & Best Practices appeared first on what. AG.

This is a positioning problem, and it’s arguably more damaging than any technical limitation. If your target audience doesn’t understand what they’re getting, they won’t buy in. And right now, most tokenized real-world asset projects are pitching infrastructure to people who just want a return.

We’re well into the tokenization era, and the gap between what the technology can do and how it’s being sold is only getting wider.

The core issue: people don’t buy tokens

Here’s the thing: nobody wakes up and thinks, “I want to own a token.” They think about rental income, portfolio diversification, access to asset classes that used to be gated off, and investments they can actually trust.

Most RWA tokenization projects lead with their infrastructure. “We tokenize assets on-chain.” “Get on-chain exposure to real estate.” These messages might land with a crypto-native audience, but they bounce right off the institutional investors, retail participants, and traditional finance professionals that this space actually needs to win over.

The more effective framing flips the script entirely:

• “Own income-generating assets” instead of “own tokens”
• “Regulated investment access” instead of “on-chain exposure”
• “A better version of TradFi” instead of “DeFi meets TradFi”

This isn’t just a copywriting fix. It reflects a deeper misalignment between what projects are building and what they’re communicating. Tokenization is infrastructure – it’s the plumbing. What investors buy is the house.

There’s also the liquidity illusion worth calling out. A lot of tokenized RWAs aren’t actively traded at all. Secondary markets are thin, holding periods are long, and volume is low. Blockchain doesn’t create liquidity by default – liquidity comes from market design, distribution, and demand. Projects that promise liquidity without building the infrastructure to support it are setting themselves up for a credibility problem.

A simple way to think about where value lives

If you strip tokenization down to its essentials, there are three layers – and most projects are focused on the wrong one.

• The technical layer is where most energy goes: blockchain infrastructure, smart contracts, token standards. It’s important, but it’s a means, not an end.

• The legal layer is where trust gets built: clear ownership rights, regulatory backing, enforceable claims. Without this, the technical layer is useless.

• The financial layer is where the actual value proposition lives: yield, liquidity, access to quality assets. This is what investors are buying.

The projects gaining real traction aren’t the ones with the most impressive tech stack. They’re the ones that have locked in the legal and financial layers and use technology as the enabler – not the headline.

Related read: builders and innovators in the crypto space are increasingly figuring this out, building products that lead with outcomes and use blockchain in the background.

What PRYPCO Mint gets right

PRYPCO Mint is one of the clearest examples of outcome-first positioning in the RWA tokenization space. It’s a Dubai-based platform that allows investors to own fractional stakes in UAE real estate.

Nowhere in their core messaging does it say “tokenized asset” or “on-chain exposure.” The pitch is: “Own Dubai real estate from AED 2,000.” That’s it. Clean, direct, and built around what investors want.

What makes PRYPCO Mint worth studying isn’t just the messaging – it’s the full structure behind it. The platform is integrated with the Dubai Land Department, meaning investors receive legal ownership certificates alongside their digital tokens. Ownership is recorded both on-chain and in government systems. This solves one of the biggest unsolved problems in RWA tokenization: enforceability. The token isn’t just a claim – it’s tied to a real title deed recognized by regulators.

The user experience reflects the same logic. Marketing focuses on rental income, low entry barriers, and property ownership. Technical language is minimal. The platform also operates on fiat rails, so users don’t need a crypto wallet or any prior blockchain knowledge to participate.

The demand signals speak for themselves – individual properties on the platform have reportedly sold out within minutes. That’s not hype; that’s product-market fit. PRYPCO isn’t selling tokenization. It’s selling access to real estate and the income that comes with it. The blockchain is the delivery mechanism, not the product.

What’s still blocking broader adoption

Even with strong models like PRYPCO Mint, the RWA tokenization space has real bottlenecks that won’t be solved by better messaging alone.

• Distribution is the first one. Who are the actual buyers, and where do tokenized assets trade after issuance? Many projects launch onto proprietary platforms without established channels into wealth management, retail brokerage, or institutional allocation. Without distribution, even a well-positioned product stalls.

• Regulation remains fragmented across jurisdictions. Compliance requirements are high, legal frameworks for digital securities vary significantly by market, and many projects are navigating this without clear precedent. The DMCC crypto and AI ecosystem is one example of how specific jurisdictions are working to create clearer conditions for this kind of innovation.

• Trust is still a hard problem. Investors need confidence that the underlying asset actually exists, that ownership rights are enforceable, and that the platform will still be operating in five years. This isn’t solved by smart contracts alone It requires legal integration, regulatory backing, and institutional credibility.

• User experience is the fourth bottleneck, and it’s often underestimated. Crypto wallets are not mainstream-friendly. The onboarding process for most blockchain-based investment platforms creates real friction – seed phrases, wallet addresses, gas fees, browser extensions. Tools like Privy are working to change this by enabling embedded wallets and simplified authentication flows that abstract away blockchain complexity entirely. The goal is a user experience that feels like any other fintech product, with blockchain running quietly in the background. That gap still exists for most RWA platforms, and it’s limiting the size of the addressable market considerably.

What this means for firms in the space

If you’re building in RWA tokenization, digital securities, or related infrastructure, the strategic implication is straightforward: stop leading with the technology and start leading with the outcome.

That means pressure-testing your messaging against what your target investor actually cares about. It means making sure your legal and regulatory foundation is solid enough to be a feature, not a footnote. And it means thinking seriously about distribution – not just how you issue, but who buys, and where they find you.

The Decentralized Science space has faced similar positioning challenges: genuinely transformative technology that struggles to communicate its value to people outside the immediate community. The pattern repeats across Web3. The projects that break through tend to be the ones that translate infrastructure into outcomes.

Tokenization has the technology. The next step is building the credibility, distribution, and user experience to match.

Ready to position your RWA or Web3 project for the right audience? Our team at what. works with blockchain startups, digital securities platforms, and crypto-native firms to build strategies that actually land. Explore our Web3 & crypto services to see how we can help.

The post RWA Tokenization’s Real Problem Is Positioning, Not Technology appeared first on what. AG.

Who is Schweizer Päckli and where did we come in?

Schweizer Päckli does something that’s harder to pull off than it sounds: they sell carefully curated packages filled with authentic regional Swiss specialties, and they make the whole thing feel like a genuine gift rather than just another online order.

Each “Päckli” is thoughtfully assembled to bring a piece of a specific Swiss region to the recipient. The contents aren’t generic. They’re selected with real attention to regional provenance, which is what gives the product its character. For someone looking to send something meaningful, that specificity matters.

By mid-2023, the technical foundation holding all of that together had started showing its age. We at what. took on a full platform migration, moving Schweizer Päckli from OctoberCMS to Laravel and Vue 3, with Laravel Nova as the backend. The project wrapped at the beginning of 2024.

Why a full migration made more sense than patching the old system

OctoberCMS had done its job. But the limitations had piled up to the point where working around them was no longer realistic.

Adding new features was nearly impossible. The dependency on CMS plugins meant little control over the underlying data structures. And scaling to new regions, a real strategic goal for Schweizer Päckli, was cumbersome at best.

The honest case for a full migration came down to this: when the architecture itself is the ceiling, incremental improvements just delay the inevitable. Going with Laravel and Vue 3 gave the project a proper foundation:

• Better performance and easier extensibility
• Cleaner data structures with fewer plugin dependencies
• A backend the client could manage independently, without needing to loop in an agency for routine updates

The technical challenges that slowed things down

SSR setup was harder than expected

The most demanding part of the project was configuring Server-Side Rendering (SSR) for the Vue 3 frontend. Because Schweizer Päckli’s shop runs as a Single Page Application (SPA), SSR is what makes it crawlable and indexable by search engines. Without it, the shop effectively doesn’t exist for Google.

The friction came from older JavaScript libraries that assumed a browser environment. The moment you try to render them server-side, they break. The team had to resolve these conflicts one by one.

What made this harder was an additional constraint: the frontend had to look exactly the same as before. The client didn’t want any visible changes to the UI. So the team was rewriting internals while keeping the surface identical, which made what would otherwise be a contained technical problem significantly more delicate.

Data migration and CSS continuity

The existing data had to move cleanly into new schemas without loss or integrity issues. Not the most exciting work, but it’s where migrations often go quietly wrong.

The CSS and SCSS situation was similar. Years of CMS-era stylesheets came with the usual baggage: specificity conflicts, undocumented overrides, styles tied to markup that no longer existed. Getting those to function correctly inside Vue 3 components, without triggering a full visual redesign, took real patience.

What we learned

The invisible work matters most

The most significant outcome nobody noticed was the PDF generation overhaul. Supplier documents look exactly the same as before on the surface. But the internal logic was completely rebuilt to handle a much larger volume of documents than the old system could manage.

It’s a pattern worth internalizing: the improvements that create the most long-term reliability are often the ones users never see. That’s not a reason to skip them. It’s a reason to protect them from being cut.

Modern stack as a prerequisite, not a luxury

On the old platform, almost every new feature request ran into the same wall. The answer was effectively: “we can’t, or it’ll cost a lot.” That’s not just a developer problem. It has direct business consequences.

After the migration, that conversation changed entirely. New regions can now be added from the backend without development work. Features that were previously out of reach are now straightforward to build.

Automated testing protects you when business logic shifts

what. introduced test cases that run before each deployment. For a business like Schweizer Päckli, where the logic around regional packages, suppliers, and orders evolves as the product grows, that’s a genuine safety net. It catches issues early, before they reach customers.

What worked well

A few things landed particularly cleanly:

• CDN setup: Images, JavaScript, and CSS files are now served via CDN across Schweizer Päckli’s multiple regional domains. Assets load faster regardless of which regional version of the site a visitor lands on. A relatively straightforward decision with a disproportionate impact on perceived performance.
• Laravel Nova backend: The client can now manage content, regions, and packages without needing to involve what. for routine updates. That kind of editorial independence reduces dependency on an agency and frees up project time for work that actually requires technical input.
• Region management: Adding a new region, which used to require significant development effort, is now a backend task. There’s also a region switcher that gives an at-a-glance overview of any regional version of the site, useful as the business continues expanding.

What’s still in progress

The migration was the foundation, not the finish line. Schweizer Päckli is actively working on further improvements to the shop, which is exactly the right posture. The new architecture supports that kind of iterative development in a way the old system simply didn’t.

Ongoing topics include shop improvements and further regional expansion. The team isn’t standing still.

Key takeaways from this project

Platform migrations are never purely technical. The hardest constraints on this project were non-technical ones: keeping the UI visually unchanged, migrating years of data cleanly, and working around legacy JavaScript libraries that weren’t built for modern rendering approaches.

The things that created the most durable value weren’t the flashiest deliverables. The PDF overhaul, the CDN setup, the test suite: these are the structural improvements that will quietly prevent problems for years. They’re also the easiest ones to cut when timelines get tight, which is exactly why they shouldn’t be.

If you’re sitting on an aging CMS and finding reasons to delay a migration, the cost of that delay is probably higher than it looks. Every feature request that gets a “we can’t” is a business consequence, not just a technical one.

If you’re thinking about a platform migration or website relaunch, what. helps businesses work through exactly this kind of process, from requirements and system selection through to implementation and go-live. Take a look at what.’s website relaunch and development services to see how we approach it.

The post How We Migrated Schweizer Päckli from OctoberCMS to Laravel & Vue 3 appeared first on what. AG.

Together with ETH Zurich, we developed the ETH Companion: an AI leadership coach built exclusively on scientific sources that supports over 3000 ETH executives. Here’s an honest look at what we learned along the way.

ETH Zurich – world-class research

ETH Zurich is one of the most renowned research universities in the world. Since its founding in 1854, it’s stood for scientific excellence across the natural sciences, technology, engineering, and mathematics.

With over 13,000 employees from around 120 countries, ETH isn’t just a Swiss institution – it’s a global player in education and research. People who work here operate in a highly complex, international environment, with correspondingly high demands on leadership and decision-making.

That’s exactly where the ETH Companion comes in.

What really makes this AI coach special

The core question at the outset wasn’t a technical one – it was strategic: how do you make high-quality leadership coaching accessible to thousands of executives without pouring huge sums into individual coaching programs? Traditional one-on-one coaching doesn’t scale. Digital coaching does.

The key is the quality of the knowledge base. The ETH Companion draws exclusively from trusted articles by ETH psychologists. No random internet content – only scientifically validated material, developed by ETH for ETH.

And that difference matters more than it might seem. A personal leadership coaching program can easily run several hundred thousand francs a year – if you’re serious about leadership development at scale. The ETH Companion scales exactly that: scientifically grounded leadership coaching, accessible to every executive, at any time.

The goal isn’t to build a chatbot. It’s about creating a tool that supports leaders through real challenges – based on approaches that work because they’re scientifically proven.

That sounds straightforward, but it’s conceptually demanding. You need to clarify very early on: what content goes in? Who curates it? How do you make sure the coach stays within scope?

These questions need answers before you write a single line of code.

Defining the MVP is harder than building the MVP

The most challenging part of the project wasn’t technical – it was defining the MVP (Minimum Viable Product).

What should be included? What comes later? Where’s the line between “good enough to test” and “too raw to show real value”? These discussions take longer than expected, but they’re crucial.

We ran scope definition workshops with the ETH team, created user stories, and built the framework step by step. It was absolutely worth it – but it takes time you need to factor in from the start.

A clear tip: start small, then scale. Focus the MVP on the absolute essentials, see if it works – and only then layer in additional features. Anything you didn’t clarify in the MVP will cost you twice as much to fix later.

User testing reveals what documents never will

The best moment of the entire project came during the user testing interviews.

Watching executives interact with the Companion – and seeing their genuine enthusiasm – was something else. It validated not just the product, but every decision that led up to it.

But user testing also gave us concrete insights we simply didn’t have before:

• How executives phrase their questions – and what that means for the coach’s conversational style
• Where the dialogue felt too generic and needed more depth
• Which entry points felt intuitive – and which didn’t

Without this phase, the product would have been worse. No document, no internal test replaces real interactions.

Security is not an optional add-on

A security audit was part of the development process – and that was absolutely the right call.

For a tool that handles sensitive leadership situations and is used by thousands of executives, security isn’t a nice-to-have. It’s a must-have.

Plan for it from the very beginning – not as a last-minute step just before launch.

What really counts: long-term integration, not short-term usage

Right after launch, the focus naturally shifts to: are users happy with the answers?

That’s a fair question – but it’s too narrow. The actual vision for the ETH Companion is bigger: the AI leadership coach is meant to become a genuine part of everyday working life over the long term, and to sustainably improve the quality of decisions executives make.

And the vision goes even further: what was built today for ETH leaders should eventually be available to large organizations outside ETH – as a scalable solution for companies that take leadership development seriously, without investing hundreds of thousands of francs in individual coaching programs.

That sets a different standard. And it calls for different metrics than “did the AI give a good answer today?”

What we’ve delivered – and what comes next

The result is a functional, stable AI leadership coach with a well-thought-out design that’s already in productive use. But what happens after launch matters just as much as the launch itself.

We’re continuing to develop it in ongoing sprints – because an AI tool like this isn’t a finished project. It’s a living product.

What you can take away from this

If you’re planning a similar project, these are the insights that really matter:

• Differentiation comes from content, not technology – the quality of the scientific knowledge base and the coach’s clear focus make all the difference.
• Start small, then scale – define the MVP scope in writing, validate it, then expand.
• User testing is not optional – treat it as a real project phase, not just a checkbox at the end.
• Security and scalability need to be considered from day one, not as an afterthought.

Curious about what AI automation could look like specifically in your company? That’s exactly what we work on every day.

The post ETH Zurich AI Leadership Coach: Our Lessons Learned appeared first on what. AG.

What Is WPBakery?

WPBakery (formerly Visual Composer) is a drag-and-drop page builder plugin for WordPress. It lets you build pages visually using a backend editor, without writing code.

It’s been around for years and ships bundled with many premium WordPress themes – which is a big reason it still has such a large install base. It’s not the flashiest tool in 2026, but still very much in use, and for good reason in certain contexts.

WPBakery in the real world: what a client project taught us

We worked with a client who needed a redesign of their homepage and key training landing pages. The site was already built on WPBakery, so switching builders wasn’t realistic – it would’ve meant rebuilding everything from scratch, which simply wasn’t cost-efficient.

Our job was to design and implement the page templates. The client would then manage and fill in the content themselves.

The new design was well received, and we used Templatera together with reusable components to make the editor as manageable as possible for the client. That part worked. But a few things were harder than expected, and they’re worth knowing about before you go into a similar project.

Some sections had to stay as hard-coded HTML blocks, because rebuilding them properly inside WPBakery’s structure would’ve been too time-consuming and expensive. Moreover, WPBakery isn’t intuitive for non-technical users. Even with reusable templates in place, our client needed hands-on guidance just to navigate the editor.

The core lesson we took away from this project: WPBakery makes sense when you’re already on it. Rebuilding a live site just to switch builders is rarely worth it. But going in with realistic expectations – about flexibility, usability, and what the tool can and can’t do – matters a lot. 

Those expectations directly shaped how we assessed WPBakery’s strengths and limitations, which our WordPress experts Janick Lüchinger and Marie Vaxelaire break down below.

WPBakery’s strengths

A note before we dive in: all of the following refers to the backend editor only. The frontend editor is widely considered unreliable and slow – most experienced developers don’t touch it.

Pros from a developer perspective

Our CMS expert Janick Lüchinger has worked with WPBakery on existing setups and sees clear value in specific scenarios:

• From a technical standpoint, WPBakery is stable – it doesn’t break things when a site is already built around it. 
• Many premium themes ship with native WPBakery elements and sometimes even a Pro license included, which simplifies setup significantly. 
• Custom elements are relatively straightforward to build, and when you know what you’re doing, you have solid control over the HTML structure. 
• Reusable templates via Templatera genuinely help streamline both development and client handover – exactly what saved us in the project above. 
• The plugin is also actively maintained, so compatibility with current WordPress versions isn’t a concern.

Pros for clients and users

For clients and users managing content themselves, WPBakery is workable once they’ve been properly onboarded. Day-to-day updates don’t require any coding, and reusable layouts reduce the risk of accidentally breaking the design. It’s not frictionless, but with the right setup, it’s manageable.

The real limitations of WPBakery

This is where our developer Marie Vaxelaire’s experience becomes especially relevant – and it’s worth reading carefully if you’re considering WPBakery for a new project.

Downsides from a developer perspective

The backend editor feels dated. On pages with a lot of content, it’s easy to get disoriented, especially when maintaining a page someone else built. Simple things like copy-pasting elements are possible but clunky – nothing like the Ctrl+C / Ctrl+V you’d expect in Elementor or Gutenberg. That friction adds up over time.

The bigger structural issue is how rigid the native elements are. If your design was created in a design tool like Figma independently of WPBakery’s constraints, achieving pixel-perfect results is genuinely hard. It often requires heavy workarounds, custom CSS, and a lot of trial and error. 

You frequently end up injecting custom code – which somewhat defeats the purpose of using a page builder in the first place. The generated HTML doesn’t help either: deeply nested containers produce bloated markup, which hurts both performance and future maintainability.

Client and long-term downsides

For site owners thinking longer-term, there are a few more things to factor in:

• AI-assisted editing is limited in WPBakery – you can’t leverage modern AI features across your workflow the way you can in newer tools. 
• Switching away later is painful, since content is locked into shortcodes; deactivate the plugin and those shortcodes appear as raw text throughout your site. 
• Many developers are also reluctant to take over WPBakery projects due to its outdated architecture, which can limit your options when you need outside help.
• And if your developer relies entirely on the page builder without coding knowledge, they may hit a wall when WPBakery can’t do something natively – the fallback is often a stack of extra plugins, or no clean solution at all.

WPBakery vs. other page builders: the short version

If your site is already running on WPBakery, staying on it is often the pragmatic choice. Rebuilding just to migrate rarely makes financial sense – especially if the site is working and clients can manage content without too much friction.

For new projects, it’s a different story. The WordPress page builder Elementor offers a more modern editing experience, better AI integration, and cleaner output. Gutenberg, WordPress’s native block editor, ships with every WordPress installation, avoids shortcode lock-in entirely, and has matured into a genuinely capable tool.

For projects needing quick, flexible setup, we often reach for Breakdance. It combines modern development practices with a clean interface and performs well without unnecessary bloat.

All three – Elementor, Gutenberg, and Breakdance – are better starting points than WPBakery if you’re building from scratch in 2026.

WPBakery still earns its place in the WordPress ecosystem – just not as a first choice for new builds.
Working with a WordPress site and not sure which setup makes sense for you? We help businesses build, redesign, and maintain WordPress websites – from strategy and design through to development and long-term support. Check out our WordPress services to see how we work.

The post WPBakery Pros and Cons: An Honest Expert Review appeared first on what. AG.

Here’s how we at what. helped DMCC build one of the most active blockchain and Web3 hubs in the UAE – and what we learned along the way.

DMCC overview: why Dubai’s hub is key for crypto & blockchain

DMCC – the Dubai Multi Commodities Centre – isn’t just another free zone. It’s a government-backed ecosystem specifically designed to attract and support blockchain, crypto, Web3, and AI companies looking to establish themselves in the UAE.

Positioned in Dubai, the city sits within eight hours’ flying time of markets representing 65% of global GDP. That geographic advantage is real – but only if the right founders, developers, and investors know about it.

DMCC’s ambition was clear: become the go-to destination for crypto and AI businesses in the region, generate qualified leads, and build a community that actually delivers value.

That’s where we came in.

Inside the DMCC Crypto Centre: a physical hub for Web3 companies

The DMCC Crypto Centre is more than a co-working space. It’s an entire floor at Uptown Tower dedicated to bringing crypto, blockchain, and Web3 companies under one roof.

Physical proximity matters in this industry. Being able to walk down the hall and meet your next investor or technical co-founder creates a network effect that no Telegram group can replicate.

The Crypto Centre offers companies not just licensing, but access to a thriving ecosystem – advisors, regulators, service providers, and other builders all working in the same space.

That infrastructure gave us something real to market.

DMCC AI Centre: building infrastructure for artificial intelligence companies

Alongside the Crypto Centre, DMCC also operates a dedicated AI Centre – part of the same technology ecosystem floor at Uptown Tower.

The strategy was the same: bring AI startups, researchers, and enterprise teams into one physical location where collaboration happens organically. The AI and crypto verticals share resources, events, and a regulatory environment that supports innovation without unnecessary friction.

For us at what., managing the digital presence of both verticals meant understanding the overlap and reflecting that in our content strategy.

DMCC’s goals: lead generation, positioning, and community growth

DMCC’s objectives were threefold: position themselves as the leading crypto and AI hub in the UAE, generate licensing leads from qualified companies, and build an engaged community around the ecosystem.

The licensing landscape in the UAE is competitive. Free zones across Dubai and other emirates all compete for the same Web3 and AI companies.

To stand out, DMCC needed to demonstrate real community value – the kind that comes from events, shared infrastructure, and access to decision-makers.

Our job was to amplify that value digitally.

How what. managed DMCC’s full digital presence

We at what. took on the full digital presence of DMCC’s technology ecosystem – specifically the crypto and AI verticals.

In practice, our work covered:

• Managing and growing all social media accounts across X, Instagram, and LinkedIn
• Live coverage of physical blockchain and AI events across the UAE
• Running and moderating the DMCC Telegram community server
• Publishing blogs and placing PR to support lead generation and positioning

We weren’t just scheduling posts. We were building infrastructure for a community that needed to feel valuable to its members and credible to the outside world.

Using blockchain and Web3 events as a growth channel

Over the course of our engagement, DMCC hosted 25+ physical events. We attended and covered 24 of them live, creating real-time content across Instagram and other channels.

But live coverage was only part of the strategy. The more important work was building a system around those events – post-event analysis that tracked what actually came out of each one.

Which conversations led to licensing inquiries? What topics generated the most engagement?

Physical events in the crypto and blockchain space do something social media can’t easily replicate: they put thought leaders, investors, and builders in the same room.

We focused on capturing that value and making it visible online.

Our greatest challenges: community building and working within strict constraints

A community only grows when everyone in it gets something out of it. That sounds obvious, but it’s where most ecosystem-building efforts fall apart.

You can’t manufacture belonging. If the people in your ecosystem aren’t getting tangible value – connections, knowledge, opportunities – no amount of content will keep them engaged.

DMCC understood this early. They built physical infrastructure, hosted regular events, and created environments where meaningful connections could form.

Our job was to amplify that signal digitally.

Marketing for a semi-government organization comes with strict brand guidelines, structured approval processes, and a small margin for error.

Early in the engagement, approval workflows created friction. Material was taking too long to get published, which matters in a fast-moving space like crypto and AI.

We worked to improve the process from the inside – mapping bottlenecks, improving communication between teams, and reducing back-and-forth without compromising compliance.

The result was a faster, more efficient pipeline for getting content approved and published – making the rest of the work possible.

Results of what.’s engagement with DMCC

We can point out the following headline results from this project:

• 800+ Web3 and AI companies licensed in Dubai through DMCC
• 24 physical blockchain and crypto events attended and covered with live content
• 10,000+ organic community members grown across social platforms

Growing from 500 to 700 licensed companies within a single year – and continuing beyond 800 – reflects what happens when lead generation, community building, and positioning all reinforce each other.

This wasn’t about one viral post or one successful event. It was about building a system where every piece contributed to the same goal.

Our biggest learning on community building

The biggest lesson from this project: community isn’t a content strategy. It’s a value proposition.

If the people in your ecosystem aren’t getting something tangible out of being there, no amount of posting will manufacture genuine belonging.

DMCC’s physical infrastructure gave us at what. something real to market. The Crypto Centre, the AI Centre, the events, the network of 800+ companies – those are genuine reasons for a founder to choose Dubai and DMCC.

Our job was to make that value visible and compelling to the right audience.

Next steps: building your crypto, blockchain, or AI ecosystem

If you’re building or scaling a crypto, blockchain, or AI project and need a team that understands both the technical landscape and how to grow an audience in it, we at what. would love to talk.

Check out our Web3 and Crypto Marketing services to see how we approach community building, lead generation, and positioning for blockchain and AI companies.

Or book a free consultation to explore what’s possible for your project.

The post How We Grew DMCC’s Crypto & AI Ecosystem to 800+ Companies appeared first on what. AG.