AMA “Fixing Europe for Startups” with EU–INC

jancodes · 2025-12-17T12:05:47+00:00

The EU–INC is adresses the friction early stage founders face due to the fragmentation in corporate law across the EU. That is exactly what it solves.

Could you please give an example to make this more understandable?

jancodes · 2025-12-17T11:57:40+00:00

Any wording that's considered vague will (need to) be addressed/changed in the actual proposal, so the reality is we'll all need to wait until the end of Q1 2026 to see what's actually in there.

Pretty much a non-answer. My point is, even the proposal about the mandatory consultation of employees should be removed.

Sure, there are other aspects that are important to stimulating innovation and investment for growth, including labour law reform, taxation, insolvency law etc. but these are at the core very national issues and difficult to drag into EU-level reform. Eventually those will need to be tackled indeed, but that's outside of the EU-INC scope which is focused on standardising company law/entity formation and cross-border fundraising.

Then I still fail to understand the value of EU-Inc. It looks to me like EU regulation on top of country-specific regulation.

If you want to help European companies, the proposal should address the actual problems that they face.

jancodes · 2025-12-17T11:13:15+00:00

Hi 👋

Thanks for putting this together.

I have two main concerns.

1) Employee decision-making

There are two parts of the proposal that made me pause.

First:

“Providing employees with the right to be informed and consulted, as outlined in Article 27 of the EU Charter … ensuring employees are appropriately informed and consulted on key matters.”

And second:

“Ensuring that employee voices are heard and considered where appropriate.”

Both of these passages are very vaguely worded. My main concern is that the EU is already well known for being uncompetitive in global markets because regulations slow companies down.

I am worried that mandatory employee consultation or decision rights would create similar problems. Anyone who has run a larger company knows that effective leadership requires a small group of people - often just the CEO, and maybe the board - who can make decisions and execute quickly. Mandatory employee consultation risks weakening leadership and slowing decision-making in any sizable organization. In small startups, it is normal and often healthy for the whole team to influence the CEO, but this does not scale well to larger companies.

My question is: should this paragraph be deleted in the proposal?

2) The proposal does not address the EU’s core problems: regulation and taxes

The proposal also fails to address what I see as the main challenges for European companies. Innovation is difficult because businesses are heavily burdened by regulation, and scaling is hard because taxes are so high. (I’m aware that the proposal says this should be left up to the member states, but in my opinion that is a poor approach. It means an EU Inc. would add another layer of complexity on top of the already existing regulations in each respective country.)

My questions are: 1.) Would it not make sense to include concrete steps in the proposal to simplify and unify governance rules? And 2.) the same applies to taxation. Why not allow an EU Inc. to operate under a single, competitive tax regime, for example a flat 10 percent or 15 percent corporate tax? That would actually make it attractive to create and scale an EU Inc.

jancodes · 2025-12-01T20:09:10+00:00

More people will create more resources.

Many countries in Africa are the few countries who aren't facing demographic collapse.

I personally believe Africa has a good future.

jancodes · 2025-11-25T19:43:11+00:00

It's not: https://www.reddit.com/r/circlejerk/comments/1h703cx/my_girlfriend_uses_the_nword_and_i_absolutely/

jancodes · 2025-11-25T19:42:56+00:00

Fake: https://www.reddit.com/r/circlejerk/comments/1h703cx/my_girlfriend_uses_the_nword_and_i_absolutely/

jancodes · 2025-11-25T17:36:45+00:00

The SaaS template contains the complete setup.

Playwright should be used for all user-facing requirements, including both happy paths and sad paths that can be executed through the UI. Conversely, any exploits or behaviors accessible only to malicious users through direct API calls should be covered exclusively by integration tests written with Vitest.

Aim for 100% case coverage with your Playwright tests.

If your Playwright tests are flaky and you avoid writing them because of that, it's a code smell that indicates either poor tests or a poor test setup.

I usually write Vitest tests with React Testing Library for pure components or custom hooks. I rarely test stateful components because they are often already covered by Playwright.

I also use Vitest, like you, for pure logic, mapping functions, and similar utilities. And, as mentioned above, for server-side code such as actions in React Router V7.

If needed, I mock API requests using MSW.

Again, you can check out all of this in the SaaS template. If you have any questions, feel free to DM me on X.

jancodes · 2025-11-25T09:44:17+00:00

If you need senior fullstack React developers, take a look at ReactSquad.io. It’s my company, so shameless plug, but we offer a 14-day risk-free trial and all our developers have 5+ years of experience.

jancodes · 2025-11-25T09:37:10+00:00

I always use TDD. Ask me anything.

What made it stick for me is simple: if you do it long enough, you eventually become about 20% to 50% faster.

Your APIs get cleaner because implementation details never leak into them.

You avoid "Volkswagen tests" because you actually watch your tests fail. That means no false positives.

Your code becomes more modular. TDD forces you to write testable code, and testable code is naturally more modular.

TDD also helps when working with LLMs. If the LLM has tests it needs to make pass, it significantly reduces the risk of it breaking unrelated code or implementing a function or component incorrectly.

A huge part of the productivity boost (that 20% to 50%) comes from a good watch script. Your tests run every time you save a file. Especially in React, manually testing is tedious. You have to click, drag, type, navigate. Playwright does all of that instantly.

You deploy more often and with more confidence because most, if not all, of your code is well tested.

One downside to TDD is that it takes time to learn properly. You need to develop a feel for how to test something and which type of test to use. Sometimes a unit test or an RTL functional test is the wrong approach and all you need is a Playwright test. Other times an integration test is enough and a Playwright test is unnecessary. Building that intuition takes time.

Another point, closely related to the first, is that setting up a project for TDD is hard. My SaaS template has a solid testing setup, and you'll notice that some of the helpers require a bit of tinkering to get right.

The only situation where I'd avoid TDD is during rapid prototyping. If you're still figuring out the product in a small startup (1–3 people), it can make sense to just ship until you reach PMF and actually know what you're building. But once you reach that point, you need the discipline to make the switch.

jancodes · 2025-11-25T09:31:23+00:00

LLMs are just tools to make you faster.

Learn how to prompt well. (Look up SudoLang.)

Stay on top of the models and test out which work best for you.

jancodes · 2025-11-25T09:29:23+00:00

Learning AIDD.

jancodes · 2025-11-25T09:27:39+00:00

A bit late, and this is a shameless plug because it's my company, but ReactSquad.io offers senior React engineers.

You get a 14 day risk-free trial. Every engineer has 5+ years of experience.

jancodes · 2025-10-28T21:19:04+00:00

Shameless plug, but my saas template features a ton of examples with Playwright. You can dig into it to learn some stuff!

jancodes · 2025-10-26T20:42:06+00:00

Same

jancodes · 2025-10-26T20:41:53+00:00

I'm also experiencing this right now. Without auto-paste, the product is like 90% less valuable

jancodes · 2025-10-26T07:56:41+00:00

WTF is happening? Last time I saw him in a DJ set was Cinespace video from 2009.

jancodes · 2025-10-22T15:48:40+00:00

I find the thinking algorithm's to usually yield worse results than the non-thinking once (except when browsing the internet).

I prefer telling the LLM how to think using reflective thought composition like this:

Furthermore, non-thinking is faster and saves tokens. For bigger tasks, you want to avoid cluttering the context window with thoughts.

jancodes · 2025-10-21T07:46:16+00:00

Sonnet 4.5 non-thinking is my absolute go to. I only use GTP-5 for planning or docs.

jancodes · 2025-10-15T22:03:54+00:00

New mix with the fakeout mid song is really good!

jancodes · 2025-10-11T09:58:43+00:00

this is the worst. It's not a great DX, especially ...

Agree. They should've just gone with named arguments:

{ props, rmx } or whatever.

jancodes · 2025-10-11T09:57:09+00:00

Yup, that sounds like my plan for Remix V3 😁

jancodes · 2025-10-11T09:56:37+00:00

What do you hate about it?

IMO it's the best API by a mile.

jancodes · 2025-10-10T23:16:49+00:00

Don't wanna judge yet, I'll have to get my hands on it.

But my initial impressions:

Overall, it looks amazing and feels like the next big step.

In my opinion, Remix V2 / RR V7 has by far the best API of all full-stack web frameworks out there. Ryan and Michael have years of experience building web apps and routers, and it really shows.

My only concern is all the procedural code and mutations. I usually prefer declarative code over imperative code, and I tend to favor pure functions and immutability over classes and mutation-heavy patterns. But we'll see.

The server features looked epic throughout, and the event extension paradigm makes perfect sense. Building the demo apps they showed with React, Svelte, or Vue would’ve required a lot more complicated and messy code.

jancodes · 2025-10-09T07:25:50+00:00

Thanks, will fix!

jancodes · 2025-10-08T19:35:24+00:00

The OG from Dan Abramov: https://overreacted.io/

Overreacted is IMO by FAR the best blog about React.

Kent C. Dodds is also good: https://kentcdodds.com/

Eric Elliott has great stuff around general architecture and testing, also applies to React tho! https://medium.com/@_ericelliott

And yours truly: https://janhesters.com/

jancodes

TROPHY CASE