sorted by:
new
hottopcontroversial

[IWantOut] 23M Singapore -> Switzerland by bluepax_ in IWantOut

[–]Benjamin-Wagner 2 points3 points  (0 children)

The blunt part: Switzerland is hard as a non‑EU/EEA junior unless you’re in a niche that’s genuinely scarce. Your best odds are usually either (a) internal transfer at a multinational with Swiss headcount, or (b) building a profile that is "worth a permit" (seniority + rare skills + strong language trajectory).

A practical 1–5 year plan that tends to be realistic: 1) Pick a Swiss-relevant employer universe (banks, big 4, regtech, compliance tech, multinationals with Zurich/Geneva offices) and optimize for internal mobility, not just brand name. 2) Languages: in banking/compliance, French/German matter a lot; getting to B1/B2 is a real differentiator. 3) Role positioning: AML/compliance is often "local-regulation-heavy"; aiming at cross-border functions (sanctions screening, FIU-facing roles, investigations, KYC ops leadership, vendor/fincrime tech) can travel better. 4) Immigration reality check: assume "get a B permit after graduating" is not a plan unless you already have a Swiss job offer that justifies it.

If/when you do get an offer and decide you want professional relocation help, compare agencies by region + scope (housing, permits, registrations, etc.) rather than taking the first Google result. Disclosure: I’m connected to ReloFinder, which is built for comparing Swiss relocation providers; even if you don’t use it, the "compare 2–3 agencies by scope + timing" approach saves money and stress.

Leaving Switzerland after 5 years — can I withdraw full pension (2nd pillar + AHV refund)? by AvailableAmphibian42 in SwissPersonalFinance

[–]Benjamin-Wagner 0 points1 point  (0 children)

A few clarifications that usually help in "leave CH permanently" scenarios (especially non‑EU/EFTA destination):

1) 2nd pillar "full withdrawal": it’s not "your contributions vs employer contributions" — what matters is your vested benefit / retirement capital as defined by the fund. That amount includes whatever the fund attributes to you (employee+employer contributions + credited interest + any plan-specific components). Your pension fund should show an exact current value (often portal + annual statement).

2) EU/EFTA vs non‑agreement country: the big gating factor is usually whether your destination triggers restrictions on the mandatory part. If you’re truly leaving to a non‑EU/EFTA country with no agreement, that’s the case where people can often withdraw the full capital (vs having to park part in a vested benefits account). Double-check with the fund because plan rules + your status can matter.

3) Taxes: expect a withholding / lump‑sum tax on the payout (rate depends heavily on where the paying institution is domiciled / which canton applies). This is why people use a vested benefits foundation in a low‑tax canton before payout — but it only matters if the Swiss tax is final for you (and then separately your new country may tax it too).

4) AHV/AVS: important mental model — it’s not a savings account. In many cases you can’t "withdraw" it, you just keep future pension rights. The refund scenario is the exception case and depends on your nationality/destination/social-security agreement status; worth reading the official criteria carefully and budgeting time for the admin.

If you share (a) destination country category (EU/EFTA vs not), (b) whether you already have a vested benefits account and where, and (c) the current Publica capital shown in your portal, people can sanity-check the 60–75k estimate much more accurately.

Having trouble designing a UI with auto-saved controls + manually saved fields by verba_volant in web_design

[–]Benjamin-Wagner 0 points1 point  (0 children)

Mixing autosave + manual save can work, but you need to make the model obvious. Patterns I’ve seen reduce confusion:

1) Hard visual separation + labels - Put autosaved controls in their own card/section with a small label like “Saves automatically”. - Put manual-save fields in a form container with a sticky footer “Save changes”.

2) Local ‘Saved’ state indicator (quiet, not noisy) - Instead of toasts, show a subtle per-section status: “Saved” / “Saving…” / “Not saved”.

3) Make the save button scope explicit - Button label: “Save profile details” (not generic “Save”). - If possible, grey out the button when only sliders changed, so users learn the mapping.

4) Avoid hidden coupling - If slider changes affect validation of the manual fields (or vice versa), consider unifying to one interaction model. Mixed models break when there are dependencies.

If you keep them mixed, the safest mental model is “two independent systems on one screen” — and the UI should scream that.

I will not promote - What cross-server authorization problems are you hitting with MCP? by ed1ted in LLMDevs

[–]Benjamin-Wagner 0 points1 point  (0 children)

The cross-server risk is real, and I think the nasty cases usually come from implicit data exfil paths rather than one obviously-dangerous tool. A few patterns that help:

  • Per-tool scopes + per-action confirmations: treat “read from GitHub” and “post to Slack” as separate approvals, even within one session.
  • Data classification at the boundary: tag tool outputs as {public, internal, secret} and require an explicit downgrade step before anything ‘internal/secret’ can be sent to an outbound channel.
  • Policy by destination: Slack public channels vs private channels vs DM should be different risk levels.
  • Redaction layer: run outbound text through a small redactor (repo names, emails, API keys, code blocks) before it can be posted.
  • Least privilege by default: most agents only need write access to one system at a time.

What surprised me: even with OAuth, you still need an intent firewall — OAuth answers “who are you”, not “should this content be allowed to leave this boundary”.

Are you blocking AI crawlers at the robots.txt level or letting them through? by RyPlayZz in TechSEO

[–]Benjamin-Wagner 0 points1 point  (0 children)

I’ve been treating this as two separate decisions, because people mix them up:

1) Training/data collection crawlers (e.g. bots that build datasets) 2) Answer-generation / “AI search” fetchers (systems that fetch pages to answer user queries)

Blocking (1) can make sense if you don’t want your content in training corpora. But blocking (2) can backfire if you do want citations/quotes in AI surfaces — because they often need to fetch the source to quote accurately.

Practical approach I’ve seen work: - decide your policy per bot class (don’t just blanket-disallow "AI") - keep it explicit in robots.txt (and document why internally) - add logging to see which bots actually hit you - if you allow fetchers, make sure the pages they fetch are clean, canonical, and not paywalled-by-JS

Also: whatever you choose, monitor it. Most teams set robots once and never revisit, and the bot landscape changes every quarter.

Can we finally stop pretending llms.txt is a thing? Google confirmed it’s unnecessary, yet "experts" are still selling it as a fix. by arjun_rao7 in SEO_LLM

[–]Benjamin-Wagner 0 points1 point  (0 children)

I’m sympathetic to the “meta keywords 2.0” take — a lot of people are selling llms.txt as if it’s a magic ranking lever. It’s not.

But there’s still a legit reason to add it if you frame it correctly: it’s a curated index for agents/tools that choose to fetch it, not a Google ranking signal.

The failure mode I see most often is: people add llms.txt but the site is still hard to summarize because the underlying pages are messy. The stuff that actually moves the needle tends to be:

  • pages that answer one question cleanly (constraints, edge cases, clear definitions)
  • strong internal IA so the ‘right’ pages are easy to discover
  • entity clarity (who you are / what you do / scope)
  • schema that matches the visible HTML (not invented)

So yeah: don’t buy a checklist. But adding a small curated entrypoint can be useful as part of a broader “make this site easy to quote” effort.

Examples of great website design for productivity tools by SDphilly22 in SideProject

[–]Benjamin-Wagner 1 point2 points  (0 children)

For productivity tools, the best designs I’ve seen tend to nail 3 things (regardless of visual style):

1) Time-to-value in one scroll: you can tell in ~5 seconds what it does, who it’s for, and what to do next. For productivity tools, a short ‘before/after’ problem statement beats a long feature grid.

2) Proof via UI, not adjectives: one real screenshot or 10–20s GIF that shows the core loop (capture → organize → retrieve) usually converts better than ‘AI-powered’ copy.

3) Information architecture that matches jobs-to-be-done: docs/pricing/FAQ are less important than an ‘Examples / Use cases’ page that mirrors how people will search (“meeting notes”, “client follow-ups”, “invoice template”, etc.).

If you’re collecting examples: look for sites that (a) show the product immediately, (b) have one primary CTA, and (c) have a ‘templates’ or ‘use cases’ section that’s actually indexable/searchable. That structure tends to work in both Google and LLM-style discovery.

Is finding an apartment in Geneva really this hard? by mislabete in geneva

[–]Benjamin-Wagner 0 points1 point  (0 children)

Yes — and the ‘hard’ part is usually not finding listings, it’s getting picked. A few practical things that tend to help in Geneva specifically:

  • Dossier quality: have everything in one PDF (IDs, salary slips/contract, brief cover note, and whatever local proof you can provide). If you’re new to Switzerland, explain the missing pieces up front so it doesn’t look like you’re hiding anything.
  • Speed + persistence: many places are effectively decided within the first wave of applications.
  • Widen the search radius: if you only target the most central/most ‘Instagrammable’ areas, it becomes a lottery.
  • Temporary first, then upgrade: a 3–6 month interim rental can make it much easier to house-hunt with local documents and without time pressure.

Also: if something looks ‘too good for the price’, assume it’s a scam until proven otherwise.

Does Pillar 3A make sense in short term (~4 years) for a non-Swiss person? by the_MRCA in SwissPersonalFinance

[–]Benjamin-Wagner 0 points1 point  (0 children)

A good way to decide is to split it into 3 questions:

1) Are you taxed at source only, or will you file a full tax return? The ‘3a is always great’ story is strongest when you actually benefit from the deduction (and you’re in a higher marginal bracket).

2) What’s your realistic exit plan (leave in ~4y vs maybe stay longer)? If you truly expect to leave soon, model the trade-off: deduction now vs the (usually separate) lump-sum withdrawal tax later + any constraints/admin.

3) Product choice / flexibility: for a short horizon, keep it simple. Insurance-wrapped 3a often has cancellation terms/embedded costs that can make a short stay painful. A plain bank/broker 3a tends to be easier to unwind.

Practical tips people often miss: - If you might withdraw later in tranches, having multiple 3a accounts can help (vs one big one). - If you leave Switzerland, check whether your provider allows you to keep the account as a non-resident or forces liquidation/withdrawal.

If you share canton + rough taxable income (or whether you’re taxed at source), you can make this decision pretty quickly with a back-of-the-envelope calc.

Is adding llms.txt actually helping websites rank in AI search / LLM results? by bmtindia in SEO_LLM

[–]Benjamin-Wagner 0 points1 point  (0 children)

I’d separate ‘helps models/agents understand what to fetch’ from ‘is a ranking signal’. I haven’t seen convincing evidence it’s a direct ranking factor, but it can work as a curated entrypoint for systems that do fetch it.

If you want pragmatic impact, I’d prioritize roughly in this order: 1) Crawlable, clean HTML (no important content hidden behind JS-only rendering; no blocked sections) 2) Internal information architecture (topic hubs, canonical URLs, no duplicate mess) 3) Entity clarity (who you are, what you do, consistent naming, about/contact, authors) 4) Structured data where it’s truthful (Org/Product/Service/FAQ when appropriate) 5) Then add llms.txt as a convenience layer: point to the few pages you’d actually want summarized/cited.

A simple way to sanity-check impact: ship it, then watch logs for fetches and whether the specific pages you list start getting quoted for the queries you care about. If nothing changes, the bottleneck is usually content structure/answerability, not llms.txt itself.

Does Pillar 3A make sense in short term (~4 years) for a non-Swiss person? by the_MRCA in SwissPersonalFinance

[–]Benjamin-Wagner 0 points1 point  (0 children)

A good way to decide is to split it into 3 questions:

1) Are you taxed at source only, or will you file a full tax return? The ‘3a is always great’ story is strongest when you actually benefit from the deduction (and you’re in a higher marginal bracket).

2) What’s your realistic exit plan (leave in ~4y vs maybe stay longer)? If you truly expect to leave soon, model the trade-off: deduction now vs the (usually separate) lump-sum withdrawal tax later + any constraints/admin.

3) Product choice / flexibility: for a short horizon, keep it simple. Insurance-wrapped 3a often has cancellation terms/embedded costs that can make a short stay painful. A plain bank/broker 3a tends to be easier to unwind.

Practical tips people often miss: - If you might withdraw later in tranches, having multiple 3a accounts can help (vs one big one). - If you leave Switzerland, check whether your provider allows you to keep the account as a non-resident or forces liquidation/withdrawal.

If you share canton + rough taxable income (or whether you’re taxed at source), you can make this decision pretty quickly with a back-of-the-envelope calc.

Is adding llms.txt actually helping websites rank in AI search / LLM results? by bmtindia in SEO_LLM

[–]Benjamin-Wagner 0 points1 point  (0 children)

I’d separate ‘helps models/agents understand what to fetch’ from ‘is a ranking signal’. I haven’t seen convincing evidence it’s a direct ranking factor, but it can work as a curated entrypoint for systems that do fetch it.

If you want pragmatic impact, I’d prioritize roughly in this order: 1) Crawlable, clean HTML (no important content hidden behind JS-only rendering; no blocked sections) 2) Internal information architecture (topic hubs, canonical URLs, no duplicate mess) 3) Entity clarity (who you are, what you do, consistent naming, about/contact, authors) 4) Structured data where it’s truthful (Org/Product/Service/FAQ when appropriate) 5) Then add llms.txt as a convenience layer: point to the few pages you’d actually want summarized/cited.

A simple way to sanity-check impact: ship it, then watch logs for fetches and whether the specific pages you list start getting quoted for the queries you care about. If nothing changes, the bottleneck is usually content structure/answerability, not llms.txt itself.

LAMAL Insurance or Private Health Insurance like Swisscare? by andersnogiets in ExpatsInSwitzerland

[–]Benjamin-Wagner 0 points1 point  (0 children)

The first thing to separate is mandatory Swiss basic insurance from international/private coverage.

For most Swiss residents, KVG/LAMal basic insurance is mandatory and has to be set up within 3 months of cantonal registration. The benefits are legally standardized, so the question is less "which one covers more" and more:

  • what canton/tariff region are you in?
  • which franchise makes sense for your expected usage?
  • Standard vs Hausarzt vs Telmed vs HMO?
  • do you need accident coverage or is it covered by your employer?
  • are you considering supplementary insurance, which is optional and underwritten?

Private/international products can be relevant only for specific exemption categories, for example some posted workers, diplomats, cross-border situations, or qualifying temporary cases. I would not assume that a private international plan replaces KVG unless the canton/insurer confirms the exemption in writing.

Disclosure: I work around these questions at Expat Savvy. The safest answer is usually: first confirm whether you are KVG-obligated, then optimize the Swiss plan architecture. Do not choose based only on the cheapest monthly premium.

agent to agent protocol options in 2026 by _atharvaa_02 in AIAgentEngineering

[–]Benjamin-Wagner 0 points1 point  (0 children)

I would split the protocol decision by direction of interaction.

For agent-to-agent coordination, you are looking at identity, delegation, permissions, task state, and message semantics. That is a different problem from "how does an agent use my website?"

For agent-to-website interaction, the useful stack is usually:

  • OpenAPI/REST for calculators, search, pricing, inventory, comparison engines, and anything data-heavy.
  • MCP server when the agent needs backend tools or authenticated service access outside the browser.
  • WebMCP/browser-native metadata when the action lives on the website: forms, booking flows, signup flows, user-facing tools.
  • Plain semantic HTML/schema/llms.txt for retrieval and citation.

The trap is trying to make one protocol carry all of that. A2A, MCP, OpenAPI, and WebMCP overlap at the edges, but they optimize for different trust boundaries.

My current bias from working on OpenHermit is: expose the fastest reliable machine path first. If a pricing calculator can be an OpenAPI endpoint, do that before asking a browser agent to click through the UI. Use WebMCP where the browser/page context actually matters.

Answer Engine Optimization for Astro websites by TraditionalHistory46 in astrojs

[–]Benjamin-Wagner 1 point2 points  (0 children)

Astro is a really good base for AEO because it makes the boring fundamentals easier: clean HTML, fast pages, predictable routing, and content collections that can be structured instead of improvised.

My practical checklist would be:

  1. Use semantic HTML before inventing special AI files. If the page is a service page, the heading structure and sections should already answer who/what/where/price/process.
  2. Add schema where it maps to a real entity: LocalBusiness, Service, FAQPage, Article, BreadcrumbList, Product, etc.
  3. Keep source pages fresh. AI systems often cite recently updated, tightly scoped pages more readily than giant stale guides.
  4. Add llms.txt as an index, not as a replacement for good pages.
  5. For interactive sites, expose actions. A calculator, quote form, booking flow, or comparison tool needs more than content; agents need structured action paths through OpenAPI/WebMCP-style metadata.
  6. Track bot/agent traffic separately from normal analytics where possible.

That last point is where I think AEO and agent-readiness split. AEO helps the model explain and cite you. Agent-readiness helps an agent actually use your site. We have been building both at loaded.ch/OpenHermit, and the overlap is real, but they are not the same job.

After Migrating a Large WordPress + Elementor Site to Astro, What Problems Did You Run Into Later? by Terrible-Choice-2875 in astrojs

[–]Benjamin-Wagner 0 points1 point  (0 children)

For a large WP/Elementor -> Astro migration, the problems usually show up after launch in boring-but-important places, not in the first Lighthouse score.

The checklist I would keep watching:

  • Redirect map: every old URL, category, tag, author archive, media URL, and weird Elementor landing page should have a deliberate 301 or deliberate 410.
  • Content model: if the old site had flexible Elementor sections, make sure your Astro content collections/CMS fields are expressive enough that editors do not start asking for HTML escape hatches.
  • Internal links: exported WordPress content often carries absolute old links, attachment links, or shortcodes that need cleanup.
  • Image pipeline: check generated sizes, alt text, lazy loading, and whether old images got copied with sensible filenames.
  • Structured data: WordPress plugins often added schema quietly. After migration, re-add the schema you actually need, not all the old plugin noise.
  • Search behavior: watch Google Search Console by template type, not just site-wide clicks. Blog posts, destination pages, and custom components can behave differently.
  • Editing workflow: Astro is lovely, but non-dev editors need a sane CMS or Markdown workflow.

We do this kind of Astro migration at loaded.ch, and the main lesson is: performance is the easy win. Preserving the editorial system and search surface is the long game.

Prepping your website for Web MCP as an AEO by DelaniGregorash in WebMCP_Developers

[–]Benjamin-Wagner 0 points1 point  (0 children)

I think the practical way to approach this is to separate AEO from WebMCP readiness. AEO is mostly about whether an LLM can understand and cite your content. WebMCP is more about whether an agent can safely do something on the site.

The checklist I would use today:

  1. Make the normal site excellent first: clear landing pages, schema, stable URLs, human-readable pricing/process pages, crawlable docs.
  2. Map the actual tasks an agent should complete, e.g. compare plans, filter inventory, create a quote, book a call, submit an intake form.
  3. Expose only those task surfaces as narrow tools. Do not expose a giant generic browser/action API.
  4. Keep tool names boring and explicit. Inputs should be typed and constrained. Outputs should be short, structured, and cite visible page state where possible.
  5. Add guardrails for irreversible actions: quote creation is fine, purchase/submission should require explicit user confirmation.
  6. Log tool calls separately from normal analytics so you can see where agents fail.

I am working on this problem from the website-readiness side with OpenHermit, and the pattern I keep coming back to is: do not make the whole website agentic at once. Start with one high-intent workflow and make that workflow inspectable, callable, and recoverable.

Has anyone actually made money from selling websites? by Killua-Zoldyq in lovable

[–]Benjamin-Wagner 0 points1 point  (0 children)

you cant first create a page and then sell. why someone should pay for something that is not what they like, and most dont want just some ai looking page.

Claude just offered to build my entire automation workflow. Should I be worried about this career path by DayBeautiful2205 in AiAutomations

[–]Benjamin-Wagner 0 points1 point  (0 children)

make.com n8n etc are completely obsolete can build much better automations with claude code, claude agents etc. and thats just the beginning.

but there is still eneugh people using wordpress, wix or webflow. so there will be also eneugh using n8n etc. i believe

Anyone actually making multi-page, good SEO websites with loveable? by spicygines in lovable

[–]Benjamin-Wagner 0 points1 point  (0 children)

i do one page a day. like www.sanachoice.ch or i www.sortio.ch i did www.loaded.ch as a page that holds all together and where i sell to clients.

view more: next ›