DEV Community: Mateusz Muszarski

How I work with Claude Code: memory, gates and the mistakes that built them

Mateusz Muszarski — Sun, 18 Oct 2026 18:26:36 +0000

This post first appeared on my site.

Claude Code has two habits that hurt on a long project: it forgets what you agreed once the context gets compacted, and it stops when the work looks done. So my setup does two jobs. It remembers for Claude (a wiki, a lessons file, three hooks), and it doesn't accept "done" until tests, gates and screenshots agree. Here is that setup, and the mistakes behind each piece.

TL;DR

Memory: CLAUDE.md is a 76-line router into a wiki; hooks hand Claude the right pages for every prompt and bring the rules back after every compaction.

Corrections compound: every correction becomes a one-line rule, and a rule that slips back becomes a test.

Done means proven: typecheck, tests, e2e, Lighthouse, and screenshots Claude has to open and look at, in every language.

Scale: subagents for research and fact-checks, background builds, and a few hard rules for parallel sessions on one repo.

This post assumes you know the basics (CLAUDE.md, plan mode, /clear); if not, the quickstart covers them in ten minutes. Both habits above come from the docs: quality drops as the context window fills, a full window gets compacted into a summary, and without a check Claude can run, "you become the verification loop".

How does it remember what I said last week?

Not in CLAUDE.md alone. Mine is a router: a table that maps a task ("copy, wording, CTA labels") to the wiki page that holds the knowledge, plus the rules that must never break. The wiki holds the rest: 33 pages, plus a folder of research notes. Three hooks, configured in .claude/settings.json, do the remembering:

Hook	When it runs	What it does
`SessionStart`	new chat, resume, `/clear`, every compaction	injects a card: how we work, what's in flight in git, the lessons
`UserPromptSubmit`	every prompt	scores the prompt against the routing table and injects up to 5 best-matching pages
`Stop`	when Claude tries to finish	blocks once if code changed but the wiki didn't

This is what Claude saw before it read my prompt "have it consistent over languages" while I was writing this post:

[project wiki] Before acting, read the pages that match this task:
- Locales, translation, Lingui, Polish, Spanish, language switcher,
  hreflang, URL prefix, slugs: .claude/project-info/site/i18n.md
Change behaviour a page describes -> update that page + append a line to
.claude/project-info/log.md in the same change.

The compaction part is the one that matters. Claude Code re-reads the root CLAUDE.md after a compaction, but not the pages it read along the way or what I said in chat. The card brings the rules back, because a script prints it again from files in git. How the wiki is laid out and how the router scores a prompt is in An LLM wiki: project memory for Claude Code.

How does a correction turn into a test?

Correction. I tell Claude it got something wrong, or a tool trips it.
Rule. One dated line in lessons.md, in the imperative.
Every session. The SessionStart hook injects the rules, after every compaction too.
Check. A rule that slips back becomes a test, a lint rule or a hook.

↻ Every new check is one correction I never have to give again.

The best example is a bug that never threw an error. Scroll-driven animations on this site are written in CSS. The build folded animation and animation-timeline into one shorthand that Chrome rejects whole, so the effect silently never ran. Nothing failed: the code looked right and Claude reported it done. On 2026-10-08 it became a rule: write these in longhands. By the next day three rules had slipped back to the shorthand anyway, so now a unit test reads every stylesheet:

it("never use the animation shorthand next to animation-timeline", () => {
  const shorthand = rules
    .filter(({ rule }) => /(^|[\s;])animation\s*:/.test(rule))
    .map(({ where }) => where);
  expect(shorthand).toEqual([]);
});

A rule shapes what Claude tries. A test decides whether it shipped. Today's rule came from this very post: I asked for a rewrite and got an English-only draft, so now "en and pl posts are one story" sits in the lessons file.

How do I hand it a big task?

In slices. The site was built one section at a time, and each slice ran the same loop: research the section, build it with real content, check it (screenshots, gates, all three languages), fix the weakest point. The loop repeats until one more pass finds nothing worth fixing. Nothing starts while the last slice has a failing check.

Two rules make long, unattended runs safe:

No invented facts. When a fact is missing, Claude writes a placeholder, marks it with a searchable tag in the code and logs it in one register. The launch build fails while any marker is left. That's what let me ask, one evening, for every remaining section in one go without questions, and review real pages the next morning instead of made-up numbers.
Ambitious first, then practical. My first look for the site was safe and I called it ugly. Since then, a design question gets three or four rendered directions, desktop and phone, and I pick. Claude is fast at making options; I'm the one who chooses.

What does "done" mean when an agent says it?

On this project, "done" is a list of commands with exit codes, not a sentence:

Gate	Fails on
typecheck, lint, unit tests	types, style, content rules (like the test above)
e2e in Playwright	axe WCAG 2.2 AA on every route, sideways scroll from 320 to 2560 px, text spilling out of its box in any language
Lighthouse, mobile	performance under 95, any other category under 100
launch gate in the build	a placeholder left in a launch build, a missing share image

Two mistakes taught me to read the output, not the summary:

The first red task hides the rest. bun run check stops at the first failing task, so a failing test once hid a typecheck error that got committed. Now every task's result gets read, and the typecheck runs again after a test fix.
A pipe hides the exit code. While writing this post, a background build ended with exit code 0 while its log said Build failed: the command piped the output through tail, so the shell reported tail's code, and the preview served 404s. Now it's a lesson: grep the log for the failure, or use set -o pipefail.

How do you make it look at its own work?

Tests don't see a ragged line break or a label spilling out of a button. So Claude takes screenshots with Playwright from phone to desktop width (390 to 1920 px), in English, Polish and Spanish, and then opens every file. Claude Code reads images, so "I checked the page" can mean it actually looked.

The first try at this shot landed on step 3: the story plays by itself. Shot again with reduced motion, it holds still on the brief.

The rest is knowing how the camera lies. Headless Chromium draws WebGL in software, so shaders look broken until it runs with --use-angle=d3d11 --enable-gpu. Phones are emulated with touch on, or hover-only parts show their mouse version. And a page that animates needs reduced motion or a fixed clock, or the shot shows a random frame.

When do subagents pay off?

When the work is reading, not writing. A subagent runs in its own context and hands back only its answer, so a hundred pages of docs never touch the main session.

Research in parallel. While planning this site I sent out 8 research agents at once, one topic each. One lesson came out of it: parallel agents share one web search budget, so prefer fetching URLs you already know.
Fact-checks. For this post, a subagent checked 12 claims against the docs in under a minute. All held, and it found one detail worth adding: auto mode is the starting mode only from version 2.1.283.
Fresh eyes. A new agent that never saw the draft reviews the rendered post: what the headings alone say, which facts lack a source.

Where do skills fit?

A skill turns a process I'd otherwise explain every time into a command. This post came out of /new-blog: an 11-step pipeline from research to cross-posting, with its own scripts. post-check.mjs lints the reading load and the SEO, capture.mjs takes the screenshots, crosspost.mjs publishes on dev.to and checks the published copy. The skill holds the judgement ("headings are questions a reader asks"), the scripts hold everything a script can prove.

Skills grow like the lessons file. When I correct a skill's output, the correction goes into the skill, with the date and my words. The /new-blog rule on numbers came from a round where I said a post "talks too many times about lighthouse and numbers". Another came from Medium: its URL import dropped every picture, because it refuses WebP. Now the skill builds a paste page with JPEG copies and checks that each picture loads.

How do you run several sessions on one repo?

I often have two or three chats open on this repo, on two computers. Every trap here happened:

One session committed another's half-done work. Now each session stages only its own paths, never git add -A.
An audit ran on another session's build, because a running preview server served the other one's output folder. Now each build gets its own folder and port.
taskkill /IM python.exe ended every Python on the machine, other sessions' servers too. Stop a server by its port's PID.
A push got rejected today, because another session had pushed in the meantime. git pull --rebase, then push.

Long builds and servers run in the background, and in my sessions Claude gets a note when one finishes, so it keeps writing meanwhile. For truly separate work, the docs suggest one git worktree per session (claude --worktree <name>). On Windows, keep it at a short path: under the temp folder, the build hit "Filename too long" and produced pages without CSS.

What is it never allowed to do?

Auto mode keeps the prompts away: a separate classifier checks each action in the background. Hooks are the other side of that trust: they run as shell commands with your full user permissions, so read any hook before you add it. On top of it sit the hard rules: never read real .env files, never commit the private context/ folder, commit only to main, push only when I say so.

Be honest about where those rules live, though. Mine are in CLAUDE.md, and the docs are clear that CLAUDE.md guides what Claude tries but blocks nothing. A deny rule in settings is what actually stops a read. That's the next thing I'm adding.

Limits

One person, one project. This is a portfolio built by me and Claude Code in about two weeks, not a team of twenty. Hooks and gates pay off sooner the more people touch the repo.
Windows. Several traps above (Git Bash paths, taskkill, long paths) are Windows-only.
The card is over its budget. It prints the lessons up to 8,000 characters, and the file has grown past that, so the rules at the end of the file get cut until I merge and prune them.
No cost numbers. I'm on a subscription and didn't track tokens per feature.
It takes setup. The wiki and hooks came from a planning phase before any product code. On a two-day script I'd write a short CLAUDE.md and stop there.

Where would I start?

Not with the hooks. Start a lessons.md today and write one line every time you correct Claude. Add one gate that Claude has to run before it says done. When a rule slips back twice, turn it into a test. The hooks come when you notice you're repeating yourself after every compaction.

Which piece to reach for when is in Claude Code skills, hooks, MCP servers and subagents. The whole build is in the case study, and the same process plays step by step in the AI section on my home page. If your team works like this, or wants to, here's my CV.

Sources

How this post was made: I wrote it with Claude Code. It drafted the text from my project's wiki, code and notes. Just a quick disclaimer for y'all out there :)

Cookieless analytics in the EU: Umami, GDPR and Poland's art. 399

Mateusz Muszarski — Sat, 17 Oct 2026 09:33:51 +0000

This post first appeared on my site.

Cookieless analytics such as Umami avoid cookies, but not the EU rule on reading information from a visitor's device. In Poland that rule is art. 399 of the Prawo komunikacji elektronicznej (the electronic communications law), and it has no exemption for analytics. Three positions are defensible: ask for consent, skip the banner but disclose and honour opt-outs, or run no analytics in the browser. This site takes the second.

TL;DR

Two rules: GDPR covers personal data; art. 399, Poland's version of the ePrivacy device rule, covers storing or reading anything on the device, cookie or not.

Still access: the EDPB treats a script that makes the browser send data as access, and art. 399 has no exemption for audience measurement.

This site: no banner, Umami without cookies, a privacy policy that says what the script reads, an opt-out, and no script at all under Do Not Track or Global Privacy Control.

Not legal advice: I'm a developer who read the primary sources for my own site. If the decision matters to your business, ask a lawyer.

Which two rules apply?

GDPR covers personal data. Analytics needs a legal basis. For a small site that is usually art. 6(1)(f), legitimate interests: processing "necessary for the purposes of the legitimate interests pursued by the controller", unless the visitor's rights override them. Art. 21 lets people object to that processing at any time, on grounds relating to their particular situation.

The ePrivacy Directive (2002/58/EC), art. 5(3), covers storing information on the user's device or reading it from there, personal data or not. Poland implements it in the Prawo komunikacji elektronicznej (Dz.U. 2024 poz. 1221), in force since 10 November 2024. The device rule is its art. 399.

"Cookieless" answers a question about cookies. The device rule asks a broader one.

What does art. 399 actually say?

In my own abridged translation of ust. 1, storing information in a user's terminal equipment, or reading what is already stored there, is allowed only if:

the user is first told, clearly and simply, the purpose and how to set conditions in their software or service settings;
the user then consents;
the storage or access doesn't change the configuration of the device or its software.

Ust. 3 lifts these conditions when the storage or access is necessary to transmit a message over a public network. It also lifts them for a service "żądanej przez abonenta lub użytkownika końcowego", one the user asked for. Art. 400 adds that consent follows the data protection rules.

Three things follow from the text:

It binds whoever stores or reads. There is no "business" condition.
It covers access, not only storage.
The exemptions are transmission and a service the user asked for. Audience measurement isn't one.

Does a cookieless script "access" the device?

The European Data Protection Board says yes, in the common case. In its Guidelines 2/2023 (§ 33), JavaScript code "where the accessing entity instructs the browser of the user to send asynchronous requests with the targeted information" clearly falls within art. 5(3).

Umami's tracker is open source, so you can check what it does. In the current code it:

reads the screen's width and height and the browser language, and sends them with each event;
reads one localStorage key, umami.disabled, to know if you opted out;
checks the browser's Do Not Track setting when you turn that option on;
sends requests without credentials by default and sets no cookie.

The Umami FAQ agrees: "Umami does not use any cookies in the tracking code". No cookies, then, but on the EDPB reading, still access. That is why the tracker's code matters more than its landing page: a vendor's promise is not a legal source.

The same guidelines (§ 56) add that being in scope "does not systematically mean that consent needs to be collected". Whether an exemption applies is judged case by case, and in Poland the exemptions are art. 399 ust. 3. Analytics fits them badly.

The Article 29 Working Party said so in 2012 (WP194): first-party analytics "are not strictly necessary to provide a functionality explicitly requested by the user". It also found them "not likely to create a privacy risk" when limited to first-party aggregate statistics, with clear information, "a user friendly mechanism to opt-out" and anonymisation. It even suggested lawmakers "might appropriately add a third exemption criterion".

The Polish act has no such criterion. WP194 predates both GDPR and the act: useful as a risk profile, not binding.

What do Polish practice and the fines look like?

UODO, Poland's data protection authority, uses Plausible Analytics on its own site. Its privacy policy says Plausible "nie wykorzystuje plików cookie i nie zbiera danych osobowych" (uses no cookies and collects no personal data) and describes no consent step. UODO doesn't enforce art. 399, though: fines for breaking it come from the President of UKE, the electronic communications regulator (art. 444 ust. 1 pkt 82 with art. 446).

The ceilings in the statute: up to 3% of the previous year's revenue (art. 446 ust. 1). With no revenue in the three preceding calendar years, or no more than 500 000 zł in that period, the cap is 15 000 zł (art. 446 ust. 3). These are maximums, not a price list.

Which positions can you defend?

Position	What you do	What it costs
(a) Consent prompt	Ask before loading analytics; load only after a yes	A prompt on the first visit; statistics only from people who agree
(b) No banner, full disclosure	Explain it in the privacy policy, offer an opt-out, and don't track when the browser sends Do Not Track or Global Privacy Control	A residual risk under a literal reading of art. 399
(c) No client-side analytics	No tracker script; at most aggregate counts from the server	You lose screen sizes, languages and click events

(a) is the safest on the letter of art. 399, and (b) matches the WP194 risk profile and the practice above. (c) narrows the question without removing it. Your server still receives IP addresses, and the EDPB guidelines (§ 55) treat an IP address sent from the user's device as in scope too.

What does this site do?

Position (b), decided on every visit:

Page loads. Only a small inline loader runs; the Umami script isn't requested yet.
Signals. Do Not Track or Global Privacy Control on? Stop: no script.
Opt-out. umami.disabled stored in this browser? Stop.
Umami. Added after the load event, counting this site's own domain only. No cookies.
Events. Values from fixed lists, such as which button or which language. Nothing typed.

Section 7 of the privacy policy, in all three of the site's languages, says what the script reads and how to switch it off. It names itself as the information art. 399 ust. 1 asks for. The switch sits on the privacy page. Storing its flag is something the visitor asked for, which is what ust. 3 pkt 2 describes. The pause button follows the same rule: it remembers your choice only after you press it (motion that respects people).

How do you wire it with Umami?

Do Not Track is one attribute: Umami's data-do-not-track will "Respect user's Do Not Track browser setting". Global Privacy Control has no Umami setting; neither the docs nor the tracker code mention it. You could cancel each send in Umami's data-before-send hook (return a falsy value), but it's cleaner not to load the script at all. A simplified version of this site's loader:

const optedOut = () => {
  try {
    return !!localStorage.getItem("umami.disabled");
  } catch {
    return false; // storage blocked
  }
};

if (!navigator.globalPrivacyControl && navigator.doNotTrack !== "1" && !optedOut()) {
  addEventListener("load", () => {
    const script = document.createElement("script");
    script.src = "https://cloud.umami.is/script.js";
    script.dataset.websiteId = "YOUR-WEBSITE-ID";
    script.dataset.domains = "your-site.com";
    script.dataset.doNotTrack = "true";
    document.head.append(script);
  });
}

The opt-out is the key from Umami's "Exclude my own visits" page, behind a switch that sets or clears it:

optOutButton.addEventListener("click", () => {
  try {
    if (localStorage.getItem("umami.disabled")) localStorage.removeItem("umami.disabled");
    else localStorage.setItem("umami.disabled", "1");
  } catch {
    // storage blocked: nothing is saved, and the loader can't read it either
  }
});

The switch on this site's privacy page. With Global Privacy Control on (emulated here in a test browser), there is nothing to switch: statistics are already off.

Umami's server matters too. In its open-source code, a session ID is a hash of the website ID, the IP address, the user agent and a salt that rotates monthly by default. No cookie is involved, but IP addresses are, so treat it as personal data under GDPR: name the basis, explain it in the policy and honour objections.

Limits

This is a developer's reading of primary sources, not a lawyer's opinion. Position (b) keeps a residual risk under a literal reading of art. 399; if that isn't acceptable to you, (a) is a legitimate answer.
Do Not Track and Global Privacy Control reach only some visitors. MDN marks navigator.doNotTrack as deprecated, with a discontinued specification, and navigator.globalPrivacyControl as experimental and missing from some widely used browsers.
The opt-out lives in one browser. Clearing site data or switching devices forgets it.
Your context changes the answer: a shop, an app with accounts or a company site is not a personal portfolio.

The other place where visitor data meets this site is the contact form, which sends mail without a key in the browser. The whole build is in the case study, and if you want to talk about any of this, here's how to reach me.

Sources

How this post was made: I wrote it with Claude Code. It drafted the text from my project's wiki, code and notes. Just a quick disclaimer for y'all out there :)

Expo in 2026: what's new, and how it compares to Xcode and Android Studio

Mateusz Muszarski — Wed, 14 Oct 2026 09:23:13 +0000

This post first appeared on my site.

In 2026, Expo is the usual way to start a React Native app, and React Native's own docs recommend it. In the last year it dropped the old architecture, made Hermes V1 its default engine and made Expo UI stable: real SwiftUI and Jetpack Compose controls, written in React. I shipped my app Linkoglot to both app stores with it from a Windows PC, and never opened Xcode or Android Studio.

TL;DR

Expo is the default way to build with React Native: the React Native docs recommend a framework and name Expo, and 86% of State of React Native 2025 respondents used Expo CLI.

What changed since SDK 54: precompiled iOS builds, React Compiler in the template, the old architecture removed, Hermes V1 by default, smaller over-the-air updates and a stable Expo UI.

Native still wins when one platform is the product, when the app lives in OS features like widgets, or when your team already writes Swift or Kotlin.

My pick: an app for both stores, built by someone who knows React and TypeScript, starts in Expo.

What is Expo, and why does React Native recommend it?

React Native gives you native iOS and Android apps written in React. Expo is a framework on top of it. It brings a CLI, an SDK of native modules (camera, notifications, audio and more) and file-based routing with Expo Router. EAS, its set of cloud services, has a free tier. The framework itself costs nothing: "Expo and the Expo SDK are free and open source (MIT license)."

React Native's setup page is direct: "if you're building a new app with React Native, we recommend using a Framework". It names one: "Expo is a production-grade React Native Framework." You can still go without one, and the same page says so.

In the State of React Native 2025 survey, 86.18% of the 926 people who answered had used Expo CLI in the last year, against 47.73% for the React Native Community CLI.

How did I ship an iPhone app without opening Xcode?

Linkoglot is my AI language-learning app, built alone and live on Google Play and the App Store since July 2026. I built it on a Windows PC. Xcode needs a Mac (Xcode 27 "will only install and run on Apple silicon Macs"), and I never opened it, or Android Studio.

Three of Linkoglot's App Store screenshots: the camera, a flashcard and a voice conversation. The Android app runs the same TypeScript screens.

The whole path ran through Expo's tools:

Write. TypeScript and React on Windows, with Fast Refresh on both phones.
Generate. Prebuild writes the ios and android folders from the app config and plugins.
Build. EAS Build compiles in the cloud; iOS builds run on Expo's Macs.
Test. Development builds on real phones, not Expo Go.
Ship. Google Play and the App Store, each through its own review.

On EAS Build, "iOS builds run on macOS runners hosted in Expo's macOS cloud". In September 2026 Expo wrote a whole post about this path, "You don't need a Mac to develop iOS apps", and added a cloud iOS Simulator, still a "limited-access preview".

Testing was the part a PC couldn't do alone, and Expo Go wasn't enough. Expo Go is the store app that runs your project with only the native code it already ships: "There is no way to get the native code into the Expo Go app". Payments, push notifications on Android and Linkoglot's iOS notification extension all need a development build, your own app with Expo's dev tools inside.

So I bought an iPhone to test on, next to my Android phone. Expo Go isn't even in the stores for every SDK now: "Expo Go for SDK 56 is not available on the Apple App Store or Google Play Store."

What changed in Expo since SDK 54?

Expo ships a new SDK every few months, each one tied to a React Native version:

Release	What changed
SDK 54, 10 Sep 2025, React Native 0.81	Precompiled React Native for iOS, React Compiler on in the template, native tabs with Liquid Glass (beta), the last SDK with the old architecture
SDK 55, 25 Feb 2026, React Native 0.83	Old architecture removed, native tabs in the default template, Expo UI for Jetpack Compose in beta, diffed updates as an option
SDK 56, 21 May 2026, React Native 0.85	Hermes V1 by default, Expo UI stable, diffed updates on by default, Expo Router without React Navigation, agent files in new projects
SDK 57, 30 Jun 2026, React Native 0.86	A small release on React Native 0.86, which "is intended to have no breaking changes"; a later patch fixes a Hermes V1 memory regression from SDK 56
SDK 58 beta, 15 Sep 2026, React Native 0.88 RC	Built for iOS 27, Expo Modules 2.0 in beta

A few terms. The "old architecture" is React Native's original bridge between JavaScript and native code. Native tabs use each platform's own tab bar, and diffed updates send only what changed in the JavaScript. React Native 0.82 was "the first React Native that runs entirely on the New Architecture", and in the 2025 survey 733 of 932 respondents had already migrated.

What got faster?

iOS builds. Since SDK 54, React Native for iOS comes precompiled. Expo saw clean builds of React Native's test app drop "from about 120 seconds to 10 seconds" on an M4 Max. It also warned: "you're unlikely to see a ~10x build time improvement in your app". SDK 56 did the same for Expo's own modules: "around 1 minute (~16%)" off the median clean iOS build.
Startup. Hermes V1 became React Native's default engine in 0.84 and Expo's in SDK 56, "bringing faster startup times". The public numbers come from one real app, Expensify, in the 0.82 post: time to interactive 2.5% faster on iOS and 7.6% faster on a low-end Android phone.
Updates. EAS Update now sends only what changed between two JavaScript bundles. In the 24 hours before the SDK 56 post, diffed bundles were "on average 58% smaller than the full bundle they replaced".
Re-renders. React Compiler memoizes components and values at build time, so you write fewer useMemo and useCallback calls by hand. Every new project has it on.

What is Expo UI?

Expo UI is "a set of components that allow you to build UIs directly with Jetpack Compose and SwiftUI from React". Since SDK 56 the SwiftUI and Compose parts are stable; the web part is still experimental. Expo's own summary: "It just exposes the primitives iOS and Android already ship, as React components."

The official example, a SwiftUI button inside a React component:

import { Host, Button } from '@expo/ui/swift-ui';

export function SaveButton() {
  return (
    <Host style={{ flex: 1 }}>
      <Button label="Save changes" />
    </Host>
  );
}

Host is the boundary: everything inside it is laid out by SwiftUI or Compose, not by React Native's flexbox. Modifiers come from @expo/ui/swift-ui/modifiers as an array, like SwiftUI's own modifier chain.

Why it matters now is Liquid Glass. Apple's docs say standard SwiftUI and UIKit components "pick up the appearance and behavior of this material automatically". Apps built with the iOS 27 SDK can no longer opt out of the new look. A control from Expo UI is the real SwiftUI control, so it changes with the OS.

To add glass yourself, give an Expo UI view the glassEffect({ glass: { variant: 'clear' } }) modifier (Xcode 26 and iOS 26 or later). Your own React Native views can sit in a GlassView from expo-glass-effect, also on iOS 26 and up.

Expo's guidance on when to use it: Expo UI where users expect the screen to look like the OS (settings, modals, pickers, sheets), and regular React Native views for your own design. Linkoglot is the second kind: its screens are NativeWind with React Native Reusables.

What else comes with Expo now?

Expo Router: file-based routes for the app, much like a web framework's. Since SDK 56 it no longer depends on React Navigation, and its native tabs get Liquid Glass on iOS 26.
Native code when you need it: the Expo Modules API "allows you to write Swift and Kotlin to add new capabilities to your app", and config plugins edit the generated native projects at prebuild. Linkoglot's iOS notification extension is generated that way.
EAS Submit and EAS Update: Submit uploads builds to both stores and "works from any OS (including Windows and Linux for iOS)". Update ships JavaScript, styles and images over the air; native changes still go through store review.
EAS Observe: generally available since 20 August 2026. It measures launch times, time to first render and time to interactive in production, on real devices.
AI tooling: Expo runs an MCP server for coding agents, on the free plan (with a monthly usage cap) since May 2026, and new SDK 56 projects start with AGENTS.md and CLAUDE.md. It's the same kind of setup I use with Claude Code.

The free EAS plan includes 15 Android and 15 iOS builds and 1,000 monthly active users for updates; the Starter plan is $19 a month plus usage.

Expo or Xcode and Android Studio: what do you trade?

	Expo (React Native)	Xcode (Swift, SwiftUI)	Android Studio (Kotlin, Compose)
One codebase reaches	iOS, Android and web	Apple platforms	Android
Your computer	Any OS; iOS builds in EAS's cloud	A Mac; Xcode 27 needs Apple silicon	Windows, macOS, Linux or ChromeOS
Language	TypeScript and React	Swift	Kotlin
UI	React Native views, or SwiftUI and Compose through Expo UI	SwiftUI or UIKit	Jetpack Compose or Views
A new OS feature	After an Expo SDK or library update, or in your own module	On release day	On release day
Shipping a fix	JavaScript over the air, within store rules; native code through review	Through review	Through review
AI in the tools	Expo's MCP server, agent files in new projects	Claude, ChatGPT and Gemini in the coding assistant	Gemini agent mode, other models through a remote endpoint

One thing the table hides: React Native developers still open the native tools. In the State of React Native 2025 survey, 68.2% built their apps with EAS Build, and 60.3% built by hand in Xcode and 55.9% in Android Studio. Expo moves those IDEs from your daily tools to the tools you open when a native build breaks. For Linkoglot, that day never came.

When are Xcode or Android Studio the better call?

One platform is the product. An iOS-only app gets every new API in Xcode on release day. Expo's SDK built for iOS 27 was still a beta on 14 October 2026.
The app lives in OS features. Widgets, watch apps and extensions are native targets written in Swift or Kotlin, Expo or not. Expo can generate them from config, but if they are most of the app, React Native is overhead.
The team already writes Swift and Kotlin. A Kotlin team that needs both platforms has its own route: JetBrains declared "Compose Multiplatform for iOS is Stable" in May 2025.

For a new app on both stores, built by someone who knows React and TypeScript, I'd pick Expo again. My reasons for Linkoglot still hold: one codebase for two stores, fast tooling, libraries ready for the hard parts, and a language I already knew. The web skills carry over too: Linkoglot uses TanStack Query, Supabase's JavaScript client and Lingui, the same libraries I use on websites.

Limits

I've shipped one app with Expo and none in Swift or Kotlin, so the native side comes from Apple's and Google's docs, not from my own hands.
The speed numbers are Expo's and the React Native team's benchmarks (the Hermes figures are Expensify's app). I didn't measure them on Linkoglot.
What I write about Expo UI, EAS Observe and SDK 58 comes from Expo's docs and posts. SDK 58 is a beta, and prices are as read on 14 October 2026.

How Linkoglot was built, from the database to both stores' rules, is in shipping a mobile app alone, and the app has its own chapter on my home page.

Sources

How this post was made: I wrote it with Claude Code. It drafted the text from my project's wiki, code and notes. Just a quick disclaimer for y'all out there :)

Astro vs Next.js for a portfolio or a landing page

Mateusz Muszarski — Mon, 12 Oct 2026 07:47:58 +0000

This post first appeared on my site, where the clips play and the version tabs work.

For a portfolio or a landing page, Astro is the better default: it pre-renders every page to HTML and ships no JavaScript unless a component asks for it. Next.js is the better call when the site is really an application, with logins, per-user data and server-side writes. This site is Astro; Clockful, the time tracker I built during my internship at Neoteric, is Next.js.

TL;DR

Astro for content: every page pre-rendered to HTML, zero JavaScript by default, interactivity opted into per island.

Next.js for apps: logins, roles and per-user data; its static export gives up cookies, redirects, Server Actions and more.

Public data: in HTTP Archive's August 2026 mobile data, 71.0% of Astro origins pass Core Web Vitals against 35.1% of Next.js origins, partly because people build different things with each.

What does each framework say it is for?

Astro's docs are direct: "Astro is the web framework for building content-driven websites like blogs, marketing, and e-commerce." It calls itself server-first, with zero JavaScript by default. The same page says other frameworks "excel at building more complex, application-like experiences in the browser: logged-in admin dashboards, inboxes, social networks, todo lists".

Next.js calls itself "a React framework for building full-stack web applications". In its App Router, layouts and pages are React Server Components by default, and you opt into client code with the "use client" directive.

Those two lines answer most of the question. A portfolio is a content site with a contact form. A dashboard is an application.

How much JavaScript reaches the browser?

In Astro, every UI component, React included, renders to HTML and CSS, and its client JavaScript is stripped out. Interactivity is opt-in per component, through islands: client:load hydrates at once, client:idle when the browser is idle, client:visible when the component scrolls into view. A page without islands ships no framework runtime.

Next.js renders on the server too, and Server Components keep their code out of the bundle. The client still runs React, though, to hydrate Client Components and handle client-side navigation, and everything a "use client" file imports joins the bundle. That pays off in an app with many screens and shared state; on a five-page portfolio it is overhead to manage.

Here is the Astro path on this site:

Build. Every page becomes HTML, with its CSS inlined in the head.
CDN. Vercel serves the files; the contact form is the one function.
Text first. The H1 is the largest paint and waits for no script.
Small scripts. Component scripts load as small modules, with no framework runtime.
Effects last. Loops and clips wait for the first interaction; shaders draw only in view.

There are no framework islands here at all. Every component is an .astro file, and the interactive parts (the pause button, the credentials tour, the writing rail) are plain scripts that Astro bundles into small modules. On the home page they come to under 10 KB, gzipped.

Can both produce a static site?

Yes, at a different cost. Astro's default is static: "By default, your entire Astro site will be prerendered". If one route needs a server, such as a contact endpoint, you add an adapter and mark that page with export const prerender = false. Everything else stays static.

This site skipped even that: no adapter, and the contact form posts to a plain Vercel Function next to the static files (how the contact form works).

Next.js can produce a static site too: with output: 'export', next build writes one HTML file per route into an out folder. The docs list what you give up, including cookies, redirects, Proxy, Incremental Static Regeneration, Server Actions and dynamic routes without generateStaticParams(). Many of those are the reason to pick Next.js in the first place.

What about content, translations and page transitions?

A portfolio is mostly writing. Astro's content collections load Markdown and MDX from folders, validate frontmatter with a Zod schema and generate TypeScript types from it. This post is one of those files: its title, description and sources are checked before the page builds. The site's three languages run on Lingui, all of it static (how the multilingual setup works).

For page transitions, Astro supports the browser's native cross-document view transitions (the CSS @view-transition rule), and its <ClientRouter /> adds SPA-style ones when you want more control. This site uses only the CSS rule: pages crossfade with no JavaScript, and readers who ask for reduced motion navigate instantly.

What does public data say?

The HTTP Archive Tech Report takes real-user Core Web Vitals from the Chrome UX Report per origin, and detects technologies on each site's home page and one inner page. Astro and Next.js in the August 2026 dataset, mobile, all origins:

Mobile, August 2026	Astro	Next.js
Origins assessed	43,850	374,612
Good Core Web Vitals (LCP, INP, CLS)	71.0%	35.1%
Good LCP	80.6%	53.1%
Median JavaScript per page	405 KB	853 KB

Read it as a picture of two populations, not a verdict on two frameworks. By their own docs, Next.js targets applications and Astro targets content sites, so part of the gap is what people build with each. The report can't separate a framework from the site built on it.

What did this site measure?

This site is Astro 7, Tailwind 4 and one variable font, served as static files from Vercel.

The home page in Lighthouse on mobile, from a local production build on 7 October 2026. The CV, blog and work pages score 96 to 100 on the same setup.

Two honest notes:

I did not build the same site in Next.js, so I can't tell you what it would have scored. That is why the comparison above uses public data.
The framework didn't earn the score alone. On the afternoon of 7 October the home page fell to 67-74 with no framework code involved: animation loops running during load, a class that restyled every element in the offscreen sections, and scripts forcing layouts. Fixing those brought it back. What Astro gave me is the starting point: zero JavaScript, so there was nothing to remove.

The same pattern shows up in Lighthouse runs on 16 developer portfolios: the immersive 3D sites scored far below the minimal ones. The whole build story is in how this site was built.

Since then I have measured one real move: yws.lu, a client site I built in Next.js in 2025. It scored 23-45 on Lighthouse performance, and 94-100 after the rebuild in Astro (Lighthouse 13.5, local, the median of 3 runs). The details are in the yws.lu case study.

When is Next.js the right call?

Pick Next.js when most screens depend on who is looking at them. Clockful, the role-based time tracker from my internship at Neoteric, is that kind of project: logins, roles, per-user data, and Postgres row-level security on every table.

The Next.js docs cover that ground in one guide: authentication, sessions in cookies, authorization in a data access layer, and Server Actions for writes. Astro can render on demand too, but its own docs point to other frameworks for logged-in dashboards. Next.js also wins when the landing page belongs to an existing Next.js product: one codebase beats two stacks for one marketing page.

When is Astro the right call?

When the site is content first: a portfolio, a landing page, docs, a blog, a small business site. You can still write React, Preact, Svelte, Vue or SolidJS where you need interactivity, and only those islands ship code. Hosting is a CDN plus a build, with a server function only where you need one.

Which one fits your kind of site?

Your site	Pick	Why
Portfolio, CV, blog	Astro	Static HTML, zero JS by default, content collections
Marketing landing page	Astro	Same, plus an island for the one interactive widget
Landing page inside a Next.js product	Next.js	One codebase, one deploy
Dashboard with logins and roles	Next.js	Server Components, auth guide, Server Actions
App with per-user data on every screen	Next.js	Built for on-demand rendering
Content site with one or two dynamic routes	Astro	Static by default, `prerender = false` per route

How do you decide for your project?

Write down what the site must do in its first year. If the list says "log in", "dashboard" or "per-user data", start with Next.js. If it says "pages, posts, a contact form", start with Astro, then measure on a mid-range phone.

The rest of what I've built is on my work page; Clockful, the role-based app, is on my CV.

Sources

How this post was made: I wrote it with Claude Code. It drafted the text from my project's wiki, code and notes. Just a quick disclaimer for y'all out there :)

Hello Wor-- I mean, Hello dev.to :)

Mateusz Muszarski — Sun, 11 Oct 2026 21:38:00 +0000

Mateusz Muszarski

Oct 11

Trying to build an Awwwards-winning brutalist portfolio: the process, the mindset and the tools

#showdev #ai #astro #performance

16 min read

Trying to build an Awwwards-winning brutalist portfolio: the process, the mindset and the tools

Mateusz Muszarski — Sun, 11 Oct 2026 21:08:59 +0000

This post first appeared on my site, where the clips play and the version tabs work.

My old portfolio was a WebGL flight from Earth to Neptune. It looked great on my desktop. On a phone it showed an “Oops!” screen. This is the story of swapping it for a poster: the versions, the research, the sites I learned from and the reasons behind each call, mostly in pictures.

How this site got built, in 47 seconds. Made in code with Claude Code: the real site filmed frame by frame, and music written in code.

TL;DR

Before: a 3D site that scored 34 on mobile Lighthouse and didn't work on phones.

After: Astro, three languages, one font, a few shaders that never get in the way, and 95 to 100 on mobile Lighthouse.

How: a project wiki before any code, research on award winners and real products, four live designs to pick from, and checks on every change.

What rules did I work by?

Six rules: most written down before the first line of code, the rest learned on the way. Everything below follows from them.

Plan before code. The project lives in a wiki that every AI session reads first.
Practical first, then wow. Impressive within 3 seconds, usable in one tap on a phone.
Research, then pick. Real sites and real screens first; I choose between live options, not sketches.
Show, don't tell. A picture or a moving demo wherever a paragraph would go.
Keep every version. So I can show how it changed, and go back.
Nothing ships unchecked. Tests, screenshots I look at myself, speed on a slow phone.

How did it go, version by version?

About four days, and every version is kept.

Before: The 3D space portfolio (Replaced)

A WebGL flight to Neptune. Beautiful on my desktop, an “Oops!” screen on phones.

5 Oct 2026: Phase 0: a wiki, no code (Kept)

Plan first, code second.

Research, requirements, brand, legal and the rules of the project, before a single component.

5 Oct 2026: Drafting Table (Rejected)

A clean system is not a good design.

Paper, cyanotype and a title-block header. It passed every check and looked forgettable.

5 Oct 2026: Four live directions (Poster picked)

The type is the picture.

Orbit, Poster, Toybox and Exhibit as working pages. Claude recommended Orbit. I picked Poster.

5 Oct 2026: Round 2: Poster everywhere (Notes)

The whole home page in Poster, three colour themes and two fonts tried side by side.

5 Oct 2026: Round 3: less text (Approved)

Less text, more to see.

Tool logos with their names, a reel per project, a shorter everything. The comps stop here and the real code starts.

6-8 Oct 2026: The site today (Live)

Built in Astro one section at a time, then reshaped by rounds of my notes on the live site.

Why rebuild it?

Here is the old portfolio in motion:

The 3D space portfolio, recorded on a desktop. Planet textures: Solar System Scope, CC BY 4.0. The clips play on the original post.

Beautiful on my desktop. Then I measured it, on 5 October 2026:

13.8 MB before the start button. 7.6 MB of it was an emoji font.
34 on mobile Lighthouse. On a throttled phone the main content took 46.9 seconds to appear.
Phones got an “Oops!” screen. The site didn't run there at all.
Only a mouse wheel moved it. No touch swipe, no keyboard.
Nothing for search engines. The raw HTML had no text to index.

Someone opening a portfolio from a LinkedIn message on a phone gives it maybe ten seconds. My old site spent them on a loading bar. It proved I can write shaders; it also proved I hadn't thought about the person on the other side.

So no preloader, no gate, no scroll-jacking, and the same content on every screen.

What is a portfolio for?

Showing your work. It sounds obvious, yet many portfolios bury the visitor under “about me” paragraphs, or pitch their tech stack as if it were sacred, and the projects end up three scrolls down. Here the projects come right after the name: “See the work” is the first button, the tools are one strip of logos, and the about-me has a page of its own.

How did the planning work?

Before any code, I wrote the project down in a wiki of markdown pages: the audience, the brand, the budgets, the legal texts. The idea comes from Andrej Karpathy's LLM Wiki: the AI keeps the wiki up to date itself, so what it learns builds up. Three Claude Code hooks put the right pages in front of every session:

Session starts. The working rules and the lessons load first.
Each prompt. A hook names the wiki pages the task needs.
The work. Claude Code builds and checks with those pages open.
Turn ends. If the code changed and the wiki didn't, the turn stops once.

↻ A mistake becomes a one-line lesson, and the next session starts with it.

More in An LLM wiki: project memory for Claude Code.

What did the research show?

Agents opened 20 developer portfolios that won Awwwards awards in 2023-2026, on a desktop and on a throttled phone (1.6 Mbps, a 4× slower CPU). Each got two scores from 1 to 5: Wow for how memorable it is, and Practicality for how fast you can reach the projects and the contact. Practicality was measured as the moment the first real link becomes clickable.

20 award-winning portfolios by Wow and Practicality (one run each, 5 October 2026)

Site	Practicality	Wow
Edoardo Lunardi	5	4
Clément Grellier	5	3
Elliott Mangham	5	3
Valentin Mor	5	2
Antoine Wodniack	4	4
Jesper Landberg	4	5
Stefan Vitasović	4	4
Grégory Lallé	4	3
Rafa de las Heras	3	4
Hiroto Sato	3	4
Ravi Klaassens	3	4
Abhishek Jha	3	4
Francesco Michelini	3	3
Lusion (studio)	3	5
Max Milkin	2	4
Corentin Bernadou	2	4
Kris Temmerman	1	4
Bruno Simon	1	5
Samsy	1	5
Jordan Delcros	1	5

Both scores 4 or more: only 4 of 20 sites

What came out of it:

An award doesn't mean usable. On the throttled phone only 8 of the 20 were usable within 3 seconds, and 9 weren't usable within 10. The four least practical (game worlds and gated intros) even had a higher average Site of the Day score than the three most practical ones.
The jury isn't hiring. Awwwards weighs design 40%, usability 30%, creativity 20% and content 10%, and the jurors are designers and developers. A recruiter asks one thing: can I find the projects and the contact?
Stunning and practical is possible, but rare. Only four sites scored 4 or more on both. What they share: real links on the first screen, and the show beside the content, never in front of it.

Here is what that looks like on a phone. First, the immersive end:

Bruno Simon: Click to start

Samsy: No links in the HTML

Jordan Delcros: About 20 s of loading

Three of the most memorable sites in the study, on the throttled phone (5 October 2026). Quoted for review; the sites belong to their authors: bruno-simon.com, samsy.ninja, jordan-delcros.com.

And the four that did both. Each one gave this site an idea:

Edoardo Lunardi: Real links on the first screen

Jesper Landberg: The show beside the content

Antoine Wodniack: Hire me in the header

Stefan Vitasović: One signature effect

Stunning and practical, and what I took from each. Quoted for review; the sites belong to their authors: edoardolunardi.dev, jesperlandberg.com, wodniack.dev, stefanvitasovic.dev.

Section ideas came from Mobbin, a library of real screens from shipped products. The topic chips above my contact form are one of them: you start with a tap, not a blank field.

Why not another 3D world?

Honestly, I love them. My last portfolio was one. But I had measured both kinds of site by then, and the trade looked like this:

	A full 3D world	This site
First screen	a loader or “click to start”	my name, my role and two buttons
Links	often none in the HTML (Samsy, Jordan Delcros)	every link is real HTML
Search engines and screen readers	text drawn in WebGL is invisible to them	real text, painted first
Slow phone	9 of 20 award winners unusable within 10 s	shaders start after the text, only while visible
No WebGL or WebGPU	an error instead of the site (Kris Temmerman)	a CSS picture underneath

So the wow stays, as a layer instead of a gate. Four shaders run on this site, all written for it with no library:

Dither field

Contour lines

Riso prints

Goo

A dither field on All projects, contour lines in every footer, riso prints and goo on My life. Each starts after the text is on screen, runs only while visible, and holds still for reduced motion or the pause button. The clips play on the original post.

How do I run the AI?

Like a small team. I brief the lead agent, subagents research in parallel, MCP servers bring real data, hooks guard the risky commands, checks gate the result, and I review it. The AI does a lot of the typing; I own the decisions.

On the home page: Watch one change, step by step

The same process as a live story: who works on each step and what it looks like. See the seven steps

The building blocks are in Claude Code skills, hooks, MCP servers and subagents.

What happened to the first design?

Drafting Table, the first look. It passed every test and nobody would remember it.

So Claude built four very different directions as live pages. It recommended Orbit. I picked Poster: brutalism with manners. Flat saturated colour, hard offset shadows, square buttons and type fitted edge to edge.

One dark field, a contour map under the title, plates staggered left and right and an X-ray lens over every capture. Calmer, and hard to read.

Now

Easy to scan first, then the show.

A wall of every project to jump from, then a plain grid of cards on a light field. The contour lines moved to the footer.

Blog covers

Before

Colours came from the card's place in the list, so a post changed colour between pages.

After

One palette per cover, and the topic drawn literally.

A scale for a comparison, a crossed-out cookie for cookieless analytics. No words.

The rule behind all six: show the thing, cut the paragraph.

What do the other pages look like?

Every page gets the same care as the home page, on a laptop and on a phone.

All projects

My life

Blog

All projects, My life, the CV and the blog at 1440 px.

The same site on a phone: home, All projects, My life and the CV. Same content, one column.

What are the small details?

The name fills the screen without JavaScript. At build time a script measures the font and works out the exact width for each line, so the name fits edge to edge before any script runs (how it works).

The home page at 390, 1024 and 1920 pixels.

Phones get the same site. Every hover effect has a twin for touch (how), and the contact form has its own write-up, bug included (a contact form on a static site).

Who else is it built for?

Everyone, including people who use the web differently. A site that only works with a mouse and perfect eyesight shuts people out, and I'd rather it didn't. So:

Motion you can stop. One “Pause motion” button stops everything, and with reduced motion turned on, everything shows its final state (how that works).
A keyboard gets everywhere. A skip link jumps past the header, every hover has a focus twin, and focus never hides under the sticky header.
Screen readers hear the full story. Hidden text adds what the eye gets from context, like “opens in a new tab”, and every button's name starts with the words you see on it.
Contrast is tested, not eyeballed. A unit test checks every colour pair, and axe runs on every page.

How do search engines know who I am?

Sitemaps and meta tags are the floor. To find me by name, and one day show a knowledge panel, a search engine has to be sure who the site is about. So every page tells it the same story:

One person, one id. The home page and the CV describe me as one Person in structured data: my name, my role, my real portrait and my profiles. Every post and My life point back to it, and the links to my profiles carry rel="me".
Real photos with real facts. My life shows my own photos, each one marked up with where and when it was taken, and listed in the image sitemap.
A named author. Every post is a BlogPosting by that same person, with an author box under it, and every outside fact has a dated source.
A footer that does the work. Every page links to the projects, the CV, the blog, its RSS feed and my profiles.
One address per page. One canonical URL, the language versions linked to each other, and a share card for every page in every language.

The build fails if a page loses its title, description or canonical, or if the structured data stops parsing.

Author box

Footer

The author box under every post and the footer on every page: the same person, the same links, everywhere.

How is every change checked?

Static. Types, lint and unit tests.
Browsers. Playwright on every page, with axe for accessibility.
Eyes. Screenshots at phone, tablet and desktop widths that I look at myself.
Speed. Lighthouse on a slow phone.

↻ Anything that fails becomes a fix, and a repeated mistake becomes a lesson in the wiki.

Nothing is done until the checks pass and I've looked at the screenshots myself.

What is it built with?

Part	Tool
Framework	Astro 7 (why not Next.js)
Language and styling	TypeScript, Tailwind CSS 4
Translations	Lingui
Repo	Turborepo and bun
Font	Anybody, a variable font (OFL)
Icons	Tabler (MIT) and Simple Icons (CC0)
Hosting	Vercel
Contact form	EmailJS behind a Vercel function, Cloudflare Turnstile
Analytics	Umami Cloud, cookieless
Tests	Playwright, axe-core, Vitest, Lighthouse
AI	Claude Code

Where did it end up?

The home page in Lighthouse on mobile, from a local production build on 7 October 2026. Lab numbers: real-user data comes after launch.

If you'd like to talk about building something like this, or about a role, my contact form is one message long.

How this post was made: I wrote it with Claude Code. It drafted the text from my project's wiki, code and notes; I set the direction, and reviewed and approved it before it went out.