u/tomerlrn

I moved most of my savings into VWCE last year (after panic-selling in 2020 and regretting it), and this January I got my first Vorabpauschale deduction for a fund I never sold.

My understanding so far:

• The tax office assumes a minimum return based on the Basiszins and taxes it in advance.
• On €10,000 in an equity ETF, that comes to roughly €41 for 2026, or €0 if you're within the €1,000 Sparerpauschbetrag with a Freistellungsauftrag set up.
• It's credited when you sell, so it isn't taxed twice.
• Distributions count against it, so acc vs dist is only a few euros apart this year.

Is that right, or am I missing something? And for those with larger portfolios, did it change whether you hold accumulating or distributing funds?

I work in an agency, helping B2B companies buy newsletter placements, and I'd rather hear this from writers than guess.

What do sponsors do that you wish they'd stop?

And when a sponsorship worked well for your readers, what did that sponsor do differently?

Especially curious to hear from B2B, tech, and finance newsletters, but any niche helps.

For eight months I had a comfortable explanation for why my website had no traffic. It was wrong, and by the time I found out, I'd lost the only season that mattered.

Last August, I quit my full time job to focus on solo founding. In September I got the idea to build a beach discovery site for Greece. I've been a software engineer my whole career so I was confident about the building part. The plan was to get indexed over winter, ride the summer search season, and monetize once traffic showed up. Greek beach searches ramp in May and peak through August. That was my window.

Winter came and there was no traffic. I told myself it was off-season, because nobody googles beaches in January, and spent most of my time building and rebuilding the product side, as that's what I was comfortable dealing with.

Spring came and there was still nothing. I thought maybe Google was punishing me for something, or maybe my hypothesis about beach discovery was wrong and nobody really researches beaches online.

Both of those were reasonable. Neither of them was ever checked.

At the end of May it got too suspicious to keep swatting away, so I finally took a full day to audit my own site. Everything was rendering in JavaScript in the browser. Google was fetching an empty skeleton of my site. It had no idea what my pages were about and couldn't match me to any search.

On June 1st I had zero clicks, 266 impressions, and an average position of 48. That's page five.

The fix took a day and a half. As of yesterday I was at 65 clicks, 5,000 impressions, and average position 12.1. Page five to page two, and still climbing week by week.

But it's the beginning of August. The season is in its final month, and rankings take weeks to build. By the time I'm actually competitive, tourists will be flying back home. I put most of what I had into this, my first solo venture. Now my runway is thin, and I'm moving out of my apartment into a room in a shared flat to stretch my finances to next season.

The lesson isn't the technical bug. It's that I had a comfortable explanation and never tested it. I assumed the problem was my product or my idea, so I kept working on those. I didn't look anywhere else, because I already had an answer that let me stop worrying.

The other thing I got wrong: I thought being good at building meant I could build something people would find. I did build a good product. But I had never run anything solo before, and I didn't understand that getting people in front of it is the actual job. I spent all my time on the part I already knew how to do.

If something isn't working for you right now, what's the explanation you've settled on? And when did you last actually check it?

I built a beach discovery site for Greece last September. Designed it in Lovable, exported it, and rebuilt it properly myself. My whole career I've been a software engineer working for agencies, and that turned out to be exactly the problem: I trusted my engineering instincts and never thought to check the fundamentals underneath them.

The plan was simple. Get indexed over winter, ride the summer search season wave, monetize once the traffic showed up. Greek beach searches ramp in May and peak through August. That was the window, and I had eight months to prepare for it.

Winter came. No traffic. I told myself it was off-season, because nobody googles beaches in January.

Spring came. Still nothing. I told myself people book late, that maybe nobody researches beaches online anymore.

I told myself a story for eight months and never once checked whether the story was true.

At the end of May, it started getting too suspicious. So I finally did a proper SEO audit on my own.

The tragedy I discovered? Everything was rendering client-side in JavaScript. Google was fetching an essentially empty page, just a skeleton of my website. It had no idea what my site was about. It couldn't match me to a single query.

June 1st:

• 0 clicks
• 266 impressions
• 0% CTR
• average position 48.1

Position 48 is page five. Nobody has ever been to page five

The fix took a weekend. I moved from client-side rendering to fully static pre-rendered pages. Build-time fetch from the database, serve complete static HTML, done.

Today, July 14th:

• 30 clicks
• 2,440 impressions
• 1.2% CTR
• average position 14

Impressions up 817%. Position improved 71%, page five to page two. It's finally starting to operate the way I dreamed of almost a full year ago.

But it's mid-July. The season is more than half gone, rankings take weeks to compound, and by the time I'm actually competitive people will be booking flights home. I bet most of what I had on this project. My runway is running low, and I'm moving out of my apartment and in with my parents to stretch it far enough to reach next season.

The lesson isn't technical.

When your numbers are bad and you have a comfortable explanation, that explanation is a hypothesis, not a fact. "It's off-season." "People book late." "We're too early." Every one of those might be true. But if you never try to falsify it, you're not running a business, you're managing your own anxiety. I didn't know what Search Console would have told me in December. That's the point. I didn't go looking, because I already had an answer I liked.

And underneath that, the real one: I believed that being a strong engineer across a lot of projects meant I could build a strong, beautiful product. I did build one. But I had no solopreneur experience, and I had never internalized that the product isn't the hard part. Getting anyone in front of it is. I optimized the thing I already knew how to do and ignored the thing I didn't.

So: do your SEO, AEO, and GEO audits. Do them on day one, not month nine. If you're running a JS-heavy site, go to Search Console right now, URL Inspection, View crawled page. If the HTML is empty, you have my problem and you don't know it yet.

Not linking the site, not trying to farm traffic off this. Happy to answer anything in the comments.

[ Removed by Reddit on account of violating the content policy. ]

I’m testing a niche travel discovery product and wanted to share the thinking behind it, since I’m trying to figure out whether the pain point is real or if the niche is too focused.

The idea started last year when some friends were visiting Greece and wanted to find good beaches.

Their discovery process was basically:

• search “beaches” on TikTok
• open Google Maps
• click through random travel guides
• ask locals if they happened to know the area

That generally works, especially for the popular beaches, but it breaks down when you have a specific situation in mind.

For example, people do not always want “best beaches in Greece.”

They want things like:

• sandy beach in Corfu with parking nearby
• calm water near Naxos with a taverna
• quiet beach in Crete with shade
• family-friendly beach that is not packed in August
• beautiful beach that does not require a 4x4

I realized there was a gap between generic travel content and actual intent-based discovery.

So I started cataloguing beaches with practical details like sand vs pebbles, shade, parking, tavernas, water conditions, crowds, access difficulty, photos, and map location. Then I built a natural-language search layer on top so people can search by what they actually want instead of browsing generic blogs.

I also added some guide-style content for SEO, but the main thing I’m testing is whether a very narrow search experience can beat generic content for a specific travel use case.

Current status:

• free product
• no signup
• around 500 views per week
• started ranking on Google even though I initially made it last September, but just last month I discovered a huge bug so it got wrongly crawled and never ranked
• mostly trying to understand if people find this useful enough to come back or share it

The questions I’m thinking through now:

1. Is this too niche, or is the niche the reason it might work?
2. What would you test first for monetization?
3. What metric would you care about most at this stage: traffic, repeat usage, email capture, search volume, affiliate intent, or something else?
4. How would you approach distribution beyond SEO, Reddit, and basic social posting?

After planning a lot of beach days in Greece, I realized that “best beaches” lists are often not very useful.

They usually optimize for popularity, but not for the things that actually decide whether the day is good:

• Is the water calm or windy?
• Is it sandy or pebbly?
• Is there natural shade?
• Can you park nearby?
• Is it packed in July/August?
• Is there a taverna nearby?
• Is it good for kids?
• Is it easy to reach without a 4x4?

My personal rule now is to search by situation, not by ranking.

For example:

• With kids: calm water, sand, easy parking, some shade
• As a couple: smaller cove, nice water, maybe harder access
• In August: avoid the famous “top 10” beaches unless going very early
• Windy day: look for beaches protected from the current wind direction
• Full-day beach: taverna, shade, parking, toilets matter more than photos

How do you choose beaches in Greece? Do you mostly rely on Google Maps, local recommendations, blogs, or just drive around and explore?

After planning tons of beach days in Greece, I realized that “best beaches” lists are often not very useful.

They usually optimize for popularity, but not for the things that actually decide whether the day is good:

• Is the water calm or windy?
• Is it sandy or pebbly?
• Is there natural shade?
• Is there ample parking?
• Is it packed in July/August?
• Is there a taverna nearby?
• Is it good for kids?
• Is it easy to reach without a jeep?

My personal rule now is to search by situation, not by ranking.

Some examples:

• With kids: calm water, sand, easy parking, some shade
• As a couple: smaller cove, nice water, maybe harder access
• In August: avoid the famous “top 10” beaches unless going very early
• Windy day: look for beaches protected from the current wind direction
• Full-day beach: taverna, shade, parking, toilets matter more than photos

How do you choose which beach to spend your beach days in Greece? Do you mostly rely on Google Maps, local recommendations, blogs, or just drive around and explore?

My co-founder and I have spent weeks building Bridge. A platform that converts REST APIs into MCP tools automatically. Parse an OpenAPI spec, get MCP tools, agents call them.

The 1:1 endpoint to tool mapping created bloat. 200 endpoints = 200 tools = the agents pick the wrong one half the time.

The obvious fix: group related endpoints under one tool with an action field. Clean. Agent sees 20 tools instead of 200.

Here's the trap, let's say you take a customers resource. If you shove every customer-related endpoint under one tool, you get 15+ actions: find, search, create, update, delete, list_orders, list_invoices, merge, archive, export, import, add_note, assign_agent, send_email, etc.

You just moved the problem one level deeper. The agent is now scanning a giant action enum instead of a giant tool list. Same confusion, different shelf.

We've been building an OpenAPI to MCP gateway and hit this immediately.

Our solution: cap at 8 actions per grouped tool. If a resource has more than 8 operations, the optimizer has to split it into meaningful sub-groups like customers, customer_billing, customer_engagement, customer_admin, etc.

Without this, everything gets dumped into the biggest bucket. With it, the LLM is forced to name sub-groups by what they actually do. customer_billing is a better tool name than customers with 8 unrelated billing actions crammed inside.

We're calling this the "fan-out problem" and we're building the cap into our optimizer.

Curious if anyone else has hit this, if so, what's your rule for how many actions is too many under one tool?

After spending the last couple months building production MCP infrastructure, here are the decisions that mattered most and the ones I'd do differently.

1. OpenAPI → MCP conversion is the easy part. Auth is the hard part.

Auto-generating MCP manifests from OpenAPI specs is straightforward — map paths to tools, extract schemas, done. The real complexity is auth. OAuth 2.1 + RFC 9728 (PRM) + PKCE is ~4 specs you need to get right before one tool call works. If you're building multiple MCP servers, do NOT implement OAuth in each one. Centralize it.

2. Credential injection is the right pattern.

Never let the MCP client see the upstream API key. Issue each end user their own OAuth client_id/client_secret. The dispatch layer validates the OAuth token, looks up the user's encrypted credential, decrypts it, and injects it into the upstream request. The MCP server is a dumb proxy — it receives identity headers and forwards to the API.

Benefits: per-user revocation (invalidate their OAuth tokens, done), per-user rate limiting, audit trail of who called what, credential rotation without touching client configs.

3. Authorization at the dispatch layer, not the MCP server.

OAuth gets you authentication ("who is this?"). Authorization ("can they call this tool?") is entirely custom. The cleanest approach: check permissions at the dispatch layer before the request reaches the MCP server. One place to enforce policy, consistent across all your MCPs.

4. STDIO is dev-only. Streamable HTTP for anything multi-user.

STDIO is single-client by design. Under concurrent load it falls apart. The spec moving to Streamable HTTP was the right call. Stateless, standard HTTP, no SSE complexity.

5. Context window is the hidden cost.

A 1:1 OpenAPI→MCP mapping gives you 30+ tools from a typical REST API. That's thousands of tokens of tool schemas in every context window. Solution: dynamic tool filtering — only expose the tools the user actually needs, not all of them. Cuts schema waste by 60-70%.

Things I'd do differently:

• Don't bother with DCR (Dynamic Client Registration). Pre-register clients. Much simpler, fewer moving parts.
• Start with a single D1/KV setup for all MCPs. Don't over-shard early.
• Log every OAuth handshake step from day one. Debugging "invalid_grant" with no context is miserable.

Happy to dive deeper on any of these. Curious what others have landed on for multi-tenant auth and tool-level authorization.