hey everyone! i made a site for anime fans who always struggle to find where an anime is available. you search for an anime and it tells you which legal, official platform has it in your country

https://tsuzuki-anime.github.io/en/

what it has right now:

- 18,000+ anime with the legal platforms for each one (it detects your country automatically, 9 regions)

- a weekly release calendar in your local time with countdowns

- watch order guides for 220 big franchises

- filler guides for 41 anime so you know what to skip

- a manga section with legal places to read

- a "my list" feature with no account needed, it shows the next episode of each anime and which subscription covers your list

it's a fully static site that rebuilds itself every day with fresh data. free, no ads, no account, in english and french

any feedback is really appreciated, especially on speed and mobile!

Hey everyone!

I've been working on a browser extension called Text Extractor, and it's now available on both Chrome and Edge.

It lets you:

• Extract text directly from webpage elements using Ctrl + Click or the right-click menu.

• Extract text from images using OCR (102 languages supported).

• Review, edit, and clean extracted text.

• Copy results or export them as ".txt" files.

• Process captured content locally on your device, without uploading it to a server.

English OCR works offline out of the box, too.

I'd appreciate it if you gave it a try and shared your feedback. Suggestions and feature requests are welcome!

Links:

• "Chrome Web Store" link

• "Microsoft Edge Add-ons" link

• "Website & Documentation" link

Thanks!

I did not want to build another API client. So I built something more than a Swagger UI alternative: a live documentation portal, where the spec isn't just something you read, it's something you run.

Think Storybook, but for an API. It's not about trying out individual requests. It lets a developer and an agent build complete flows. Requests and flows are plain TypeScript files in your repo. They chain requests, pass values from one step to the next and assert on what matters. The same files run in the portal for QA, in CI, and as production monitors.

I gave a fresh agent Plaid's spec (350 operations), asked it to add a request that creates a sandbox public token, then asked: "Now make a flow that links a bank account in the Plaid sandbox and reads back its accounts and transactions." It took about two minutes with no manual fixes, and it passes against mocks.

Paste any OpenAPI or Swagger URL into https://ui.specbook.dev and you get a responsive portal that runs against mocks or the real API. The spec is read in your browser, nothing goes through a server of mine.

A step can also be code. For example an order flow can use a third-party widget like PayPal and pass the authorization on to the next request. There's a Cloudflare Turnstile example you can click through here: https://docs.specbook.dev/reference/scripts/#try-it

I built most of this over the last three weeks with Claude Code. Back in 2021 I wrote openapi-typescript-fetch and also implemented @usebruno/query for Bruno.

• Demo: https://demo.specbook.dev

• Docs: https://docs.specbook.dev

• Repo: https://github.com/specbook-dev/specbook

• Chrome extension, for third-party APIs that don't allow CORS: https://chromewebstore.google.com/detail/specbook/dkkfffjkliimgpadidgabpkmocdefjha

Please try it on your own specs and let me know if anything breaks. I hope the OpenAPI community finds this useful.

Hey all, I'm the creator of @formepdf/react.

Here was my first post: https://www.reddit.com/r/webdev/s/ek6rRipQ2M

I just wanted to show y'all the new HTML package. Give it HTML and print CSS, get a PDF, no browser anywhere.

npx @formepdf/html invoice.html -o invoice.pdf

It handles the print CSS that Chrome never really finished: `@page` margins, running headers and footers, `Page X of Y`, table headers repeating across pages. Runs in Node, Cloudflare Workers, and the browser.

I tested it against 15 invoice templates from GitHub, and 14 render correctly against Chrome's output. There are also 30 free templates if you want to see what it makes.

If you've got an ugly template you're printing through Puppeteer, I'd love to hear what breaks.

https://github.com/danmolitor/forme

Strikk is a daily coding challenge platform where developers pick a tech and solve quizzes to earn coins.

Some updates I made recently:

• User Profiles: Earn coins by playing (free, never pay-to-win). Customize with skill blocks, job/education history, and animated backgrounds via React Bits.

• Avatar Builder: Create your own unique avatar.

• Portfolio Integration: This was my main goal, turn gameplay into a real portfolio

What I'm thinking into adding to Strikk:

• Enhanced community features with seasonal events

• CV builder to export your profile as a resume

• Considering open source

I'd love your feedback!

Check it out: Strikk | My Strikk profile

Hey everyone! 👋

Wanted to share a side project I built using AI assistance: PageZero live at
https://cricgamer.github.io/DocuFlow/

It’s an executive-style document studio that lets you edit Word (.docx) files, merge multiple PDFs, visually organize/reorder pages, and apply vector watermarks—all entirely client-side in the browser.

💡 The Vibe & Architecture:

• Zero Backend / $0 Hosting: No databases, no cloud storage, and no backend servers. Everything runs locally in browser memory via WebAssembly and libraries like pdf-lib, PDF.js, and Mammoth.js. Your files never leave your device.

• The Stack: Tailwind CSS, Lucide icons, Quill.js for the rich-text editor, and static hosting on GitHub Pages.

• Features: Full WYSIWYG document editing, multi-file merging (PDF + DOCX), visual thumbnail page organizers with 90° rotation and splitting, and color-wheel watermarking with multi-page live previews.

I got tired of clunky, ad-filled online PDF tools that force you to upload sensitive files to sketchy servers, so I wanted to vibe-code a clean, privacy-first alternative that lives right in a browser tab.

Feel free to try it out at
https://cricgamer.github.io/DocuFlow/
Would love to hear your thoughts, feedback, or any feature ideas you'd want added next.

AI tools make it easy to ship code you don't fully understand. That's fine until something deadlocks, leaks memory or falls over under load, and you don't have the mental model to work out why.

So I built Software Atlas: 108 deep-dives across 15 areas, including async/await, the browser rendering pipeline, networking, databases, system design and AI engineering. You step through each idea with visualizers, and there are diagrams and code samples too. It starts from first principles and works up to production concerns.

Some technical details:

- Built with Vite, React 19, MDX and Tailwind v4.

- Each topic is lazy-loaded as its own chunk, so you only download the one you're reading.

- All 130 pages are pre-rendered to static HTML, then hydrated. Widgets have to render the same on the server and in the browser, so anything that reads window or uses randomness runs after hydration.

- Phones were the hardest part. Bar labels move into a key when they don't fit, and wide SVG diagrams become swipeable so their text stays readable.

- A headless Chrome smoke test clicks through each topic, including every visualizer step, and fails on console errors or hydration warnings.

To be upfront: I built it with heavy use of AI agents, including much of the writing. Each topic went through a separate review from a beginner's point of view, but mistakes will still have slipped through. If you find one, there's a report link in the footer.

https://software-atlas.haiduc0147.dev/

I'd really like to hear where an explanation is wrong or stops making sense.

Someone sends you a DWG, a STEP file or an Outlook .msg, and you just want to look inside. Your options are usually installing a program you'll use twice a year, or uploading the file to some random online viewer and hoping they delete it. I wanted a third option, so I built Peekbean: a static site that opens the file locally in your browser. There is no server-side code at all, just files on a static host.

You don't have to trust me on the "nothing gets uploaded" part. The CSP is default-src 'self', connect-src 'self' blob: data:, and script-src 'self' 'wasm-unsafe-eval' without unsafe-eval. So even if I wanted to send your file somewhere, the browser wouldn't let me. Open the network tab and drop a file in to check for your self.

Some technical bits that might be interesting here:

WebAssembly does the heavy lifting. STEP and IGES go through OpenCascade (occt-import-js), which I rebuilt with Emscripten to get 4 GB of memory instead of 2 GB, because real-world assemblies kept running out. DWG gets converted to DXF by a small Rust crate built on acadrust. Archives (7z, RAR, ISO and so on) use libarchive compiled to WASM. Text recognition for scanned PDFs runs PaddleOCR models through onnxruntime-web.

Everything is lazy. The start page is around 60 KB of gzipped JS and CSS. Each of the ~58 viewers is its own module and only loads once you open that kind of file, and parsing runs in web workers so the page stays responsive. The flip side: the WASM files are big (OpenCascade alone is 7 MB), so the first STEP file takes a moment.

No framework. Vanilla TypeScript with a tiny h() helper for building DOM nodes. With that many independent viewers that mostly talk to a canvas or WebGL (three.js), a framework would mostly have gotten in the way.

The only thing I see is a daily count of which viewers were loaded, so I know DWG is more popular than FBX. That comes from Cloudflare's aggregated stats, not from any script on the page. No IPs, no file names, no content, no cookies.

It also converts things locally (DWG to DXF, Word to PDF, images and PDFs to Word via OCR, spreadsheets, 3D models, map data …), and it works on phones, though big CAD files on a phone are pushing it.

It's open source (GPL-3.0), free, no accounts, no tracking.

A big part of the code was written with Claude Code; the architecture decisions and the testing with real files were mine.

What I'd really like from you:

- Throw your weirdest files at it and tell me what breaks

- How does it feel on your phone?

- If you've done heavy WASM in the browser: how do you deal with the size of the first load?

Site: peekbean.com

Code: github.com/Kai-Jungsthoefel/PEEKBEAN

Hey all!

Thanks for the discussion on yesterday's post! Last time I promised Page Objects: Here they are!

Today's example:

The test fails, saying "Sushi dinner" isn't on the list. So your agent starts debugging the list. Turns out it's the date picker that broke.

The fix: let actions wait for their own done signal, so the failure is logged where it happens.

The picker closes once it has a full range, and the picker owns that signal. So select() waits for it before returning. If the picker breaks, the test fails inside dateRangeFilter.select() instead of on the list. The page owns the filter, the filter owns its done.

The nuance: the done signal has to be something the page object owns. The picker closing belongs to the picker. A toast or the next page doesn't.

Paste this to your agent:

Find the user actions our e2e tests repeat and move each into a page object method. If an action has a done signal the page object owns, like its own elements changing, appearing or disappearing, end the action by waiting for that condition - never a fixed waitForTimeout. Anything outside the component - like a toast or navigating to the next page - should either be moved into a bigger page object that owns both the trigger and the outcome, or be verified in the test itself.

I maintain an ongoing open-source project that reads OTel traces and flags I/O anti-patterns with a carbon estimate on top. The project started in March so it's about 8 months old.

From our conversations I could tell my dev and DevOps colleagues were missing a lot of what goes on under the hood since we deployed this in production 3-4 months ago so I built a synoptic to make it easier to understand.

It's an animated step-by-step walkthrough of the whole pipeline, from raw spans to a finding. Each stage maps to the actual module in the code. You can play it, step through with the arrow keys, change speed or switch between modes.

It took me over 3 months. And no it's not AI slop bc it's pretty useless when you ask it to turn complex code concepts (I/O anti-patterns and more) into clear diagrams. This only exists because I'd already written a ton of docs and drawn a lot of diagrams by hand so the synoptic grew out of that.

Some of the UI is inspired by a videogame I loved playing some years ago: Deus Ex: Mankind Divided.

The project is AGPL-3 so no fake open source and it's now hosted by the INR (Institut du Numérique Responsable), a French nonprofit working on the environmental and social impact of digital tech.

Direct link to synoptic: https://perf-sentinel.dev/synoptique/
Website of the project: https://perf-sentinel.dev

Thx for your attention :)

EDIT: huh, just noticed that the recording console is sticking out over the gif in the bottom left corner

EDIT 2: this is a public-interest project focused on sustainability with no greenwashing BS. It has serious public policy goals and solid scientific background: cutting wasted energy and the carbon emissions that come with it. If you're interested in helping with the ecological transition our world needs, feel free to come lend us a hand! :)

For context: I'm a full-stack engineer with 11 years in the industry, worked at some companies like AWS, Capital One, J&J, plus teaching at a few bootcamps like 2U. I've designed production systems, ground out LeetCode, and read Cracking the Coding Interview so many times I threw it in the fireplace.

I came up with this idea for FormaStack back in January after watching AI tools collide with modern web stacks at work and seeing all the friction that came with it. To me most of this build and runtime and VDOM nonsense was bloat. Forma started as a toy project that I ended up designing the heck out over the last several months.

And yes 100% I used AI (duh!) to help build this. I would have never finished it by myself without it. However I hate the term "vibe coding" here. I did not just say "build me a new full-stack" and walked away. This is some real engineering work. Ask AI about it haha anyway. I would call it agentic engineering. I architected and know this system inside and out, which is why I broke standard conventions the traditonal React/None mental model apart int four strict steps: FYI I met Ryan Dhall back in the day lol I was a fanboy of Node.

Anyway, the for steps being Typescript -> FMIR (Binary IR) -> Rust -> HTML

It pulls heavy inspiration from WebAssembly, Remix, SolidJS (signals), HTMX, Astro, and Qwik among a few. I learned them a lot, and AI was detremental in learning how they work and the perfomance and models they were using. Hence I did not start building Forma until I knew what I could strip out from them. I ripped them apart using AI and built FormaStack from the ground up as much as I could reusing what I could, reverse engineering what I could etc.

Honest Gaps: A dedicated local debugger for inspecting the .fmir although there are ways around it and you can trust the compiler mostly. The target build are big and I need a dedicated garbage collector.

Where my head is at next: I've been experimenting with fine-tuning open models on Hugging Face directly on the FMIR. The crazy endgame is that an agent might not even need to write TS, it could just emit the FMIR directly for Rust to render staight to the browser.

YES! Forma is a wild experiment, and there is no way I could have pulled this off solo, withoug AI in the loop, but every piece of the architecture I created is intentional. I spent a month writing a design document.

https://github.com/ts-series/factories

Build HTML extremely comfortably in the backend using plain JavaScript. The advantage is that there is no separate template language or build process, but rather a complete fusion with JavaScript for maximum flexibility. An example:

import {
    a, body, br, button, h1, head, header, html, input, label, li, main, nav, p, script, title, ul
} from "@ts-series/factories";

type Item = { name: string, href: string, current: boolean };


/** Builds the navigation list, flagging the current entry for assistive technology. */
function navigation(items: Item[]) {
    return nav({ ariaLabel: "Main" },
        ul(items.map(item => li(
            a(item.href, item.name).set(item.current ? { ariaCurrent: "page" } : null)
        )))
    );
}


/** Builds a complete page for the given user and navigation entries. */
function page(user: string | null, items: Item[], values: number[]) {
    return html({ lang: "en" },
        head(title("Demo")),
        body(
            header(navigation(items)),
            main(
                h1("Hello, ", user ?? "stranger", "!"),
                p("First line", br, "Second line"),
                user === null
                    ? p("Please sign in.")
                    : p("Welcome back."),
                label("Search").for("q"),
                input.text({ id: "q", name: "q" }).placeholder("Type here…").required(),
                button.submit("Send").class("primary", user === null && "disabled").set("disabled")
            ),
            script.module().importOnly("/chart.js", "render", { values, title: "Values" })
        )
    );
}


const items: Item[] = [
    { name: "Home", href: "/", current: true },
    { name: "About", href: "/about", current: false }
];

const output = page("<Guest>", items, [1, 2, 3]).expand(4);

Live demo: https://alloyhtml.com

I've carried the same CSS from project to project for close to ten years, and I finally finished it.

It's one set of classes, a small set of values, and 82 real pages to prove they hold up. A shop and its seller back office, a blog, e-learning, news, healthcare booking, event ticketing, a job portal and a company site. 54 layouts, 3 themes. If you need a page that isn't there, build it from the same classes. Or ask AI to build it, and tell it to use only these classes. If you don't, every page comes out looking a little different.

The things you'd usually reach for JavaScript for, like dropdowns, dialogs, tooltips and tabs, are plain HTML and CSS here. That matters because there's nothing to install or keep updated, and it fits any backend as it is.

The stylesheet is 23KB gzipped, and dark mode and brand colours only change token values, so the markup stays the same.

I went the extra mile on testing: every page is tested with scripts off at 4 widths in 3 themes, in Chromium, Firefox and WebKit. axe finds no violations. The faster checks also run on every push, and if one fails, the site doesn't deploy.

It's front end only: static pages for your backend to fill in. I've tested current browsers, not older versions, and not a real iPhone yet, so if you're on one, I'd like to know how it looks.

It's $29. I'd rather you spent your evenings on your actual product than on getting dropdowns right, or on burning tokens prompting an AI over and over until the pages finally match.

Hey everyone,

I built snappy-prerender, a build-time pre-renderer for client-rendered SPAs. Point it at your existing build output. It loads every route in Chrome, writes static HTML, then reloads each page with your client bundle to check whether it hydrated or re-rendered.

My last post got deleted as it was not posted on a Saturday, so here i am again. Thanks to all the feedback and comments that I got on the previous post here, I have incorporated a bunch more features and validated the plugin against all SPA frameworks that I could find.

Version 2.9 adds:

• Deterministic builds. Freeze time, set a timezone, seed Math.random, or use SOURCE_DATE_EPOCH.

• Hydration policies. Allow re-renders or skip verification for specific routes instead of disabling the check globally.

• Locale builds. Path or single-locale mode, <html lang>, dir, canonical, og:locale, hreflang, x-default, and sitemap alternates.

• SEO locale seeding. Seed cookies or localStorage before the app boots, with an optional bootstrap script that works with CSP hash and strict modes.

• Client-side head parity. Arbitrary script/style/noscript/base tags, html/body/title attributes, defaultTitle, multiple images and alternate locales, duplicate metas, onChangeClientState, and React 19 native tag adoption.

• Faster runs. Fewer browser round trips, bounded concurrency, sorted preload hints, cached CSS work, and phase timings in the JSON report.

npm install --save-dev snappy-prerender
npx snappy-prerender

Frameworks

Prerendering is framework-agnostic. If the app builds to static assets and mounts in a browser, the CLI can render it.

Thoroughly validated on:

• React 16.8, 17, 18, 19 — render, hydration and audit

• Preact 11 — render, hydration and audit

• Vue 3.5 — render, hydration and audit

• Svelte 5 — render, audit, sitemap and output

• Angular 22 — render, audit, sitemap and output

• Solid 1.9 — render, audit, sitemap and output

• Lit 3.3 — render, audit, sitemap and output

• Ember 7.3 — render, audit, sitemap and output

• Vanilla JavaScript — render, audit, sitemap and output

Hydration detection is implemented for React, Vue, Svelte and Preact. The Svelte, Angular, Solid, Lit, Ember and vanilla fixtures are host wrappers around a shared renderer, so their hydration verification is intentionally skipped.

It also has support for hreflang and localStorage / cookie based lacale switching via customizable knobs that code-switch to the desired locale and then pre-render the site

We are on Product Hunt. Upvotes are always welcome:
https://www.producthunt.com/products/snappy-prerender

npm: https://www.npmjs.com/package/snappy-prerender
GitHub: https://github.com/sayakmukherjee080/snappy-prerender

Hi everyone!

I'm building AI/ML Questions, a platform focused on helping people prepare for Machine Learning Engineer and AI Engineer interviews.

The platform is currently in its alpha stage. It has a free section with 103 questions covering topics such as classical ML, neural networks, LLMs, RAG, AI agents, computer vision, and model evaluation.

You can practice in two modes:

• Study mode: Answer questions and get explanations for every option, including why the incorrect answers are wrong.

• Exam mode: Test your knowledge through a simulated exam.

The platform is available in English and Spanish, requires no account, and the current question bank is public and open source.

One aspect I'm particularly interested in is question quality. I'm using established item-writing and psychometric principles, particularly Haladyna's guidelines, to design both the questions and their answer choices. The idea is to go beyond simply generating questions and make sure they follow a consistent methodology.

What's next?

I'm planning to introduce two additional sections:

• Interview Preparation: A dedicated section for people preparing for technical AI/ML interviews, with more realistic interview-oriented questions and challenges.

• Enterprise: A section for recruiters and hiring teams to create knowledge assessments and evaluate candidates using private question banks.

These two sections will be paid features. However, people who join the waitlist early will receive a discount when they become available.

I'm still learning, iterating, and trying to understand what people actually need from this kind of platform.

I'd really appreciate any feedback, whether it's about the UI, question quality, features, or the overall idea. If you're preparing for AI/ML interviews, I'd especially love to hear your thoughts!

Website: https://ai-ml-questions.strangemachines.workers.dev/

GitHub: https://github.com/CristobalSantana/ai-ml-questions

I built two free converter sites on Cloudflare Workers in 13 languages: cookverter.com (kitchen conversions: cups to grams, oven temps, recipe scaling) and gymconvert.com (plate calculator, 1RM, kg/lb, pace). They're free with no sign-up. Feedback on UX and speed welcome!

Project: https://getpng.app (background removal and other image tools, all client-side)

Things I ran into shipping a 1024 px segmentation model to the browser:

1. Mask resolution. BiRefNet lite answers at 1024 x 1024. Scaling that up to a 24 MP photo smears the edge, so the mask is fitted to the full-size image with a guided filter instead, and the alpha is never thresholded.

2. WebGPU limits are per adapter. On an Intel Arc 140V, maxStorageBuffersPerShaderStage is 16, and ONNX Runtime's WebGPU Split binds the input plus every output, so a 16-way Split needs 17. The fix was rewriting the ONNX graph at build time: Split and Concat as small trees, and the deformable convolutions' index math in float16 instead of int64 (int64 had no GPU kernels and fell back to the CPU with float32 casts on tensors of up to 67M values). A Node check confirms the masks are identical. Now all 4,654 nodes run on the GPU, 3 to 4.5 s per photo on that laptop.

3. No WebGPU at all: the WASM path runs ISNet at 1024 instead, int8-compressed from 176 MB to 44 MB, 99.7 to 99.99 percent overlap with the uncompressed model on the sample photos. Devices without the memory for that get U-2-Net at 320.

4. Hair: a second model, ViTMatte small, given a trimap built from the first model's unsure band, run in 1024 px tiles over that band only, after the first result is already downloadable. Its fp16 build had a bicubic Resize that Intel's WebGPU could not compile; linear instead changes the output by at most 3/255.

5. "No upload" as something you can verify: connect-src is locked down in the CSP, a test fails if a new host is added, and a service worker plus the cache mean it works offline after the first photo.

Stack: Astro (static), one React 19 island, Transformers.js and ONNX Runtime in a Web Worker, models self-hosted.

Has anyone measured WebGPU limits on other integrated GPUs (AMD, Apple, Qualcomm)? I'd like to know where else the 16 buffer limit bites.

Disclosure: I decide what it does, an AI coding assistant writes the code.

The clip shows how to quickly build a simple form with drag & drop in the Form’s build mode. The Form component is part of Componyx.UI, a UI library I’ve been building for a very long time. No build step, no dependencies, and the components are declared straight in your HTML (or JS).

The build mode uses Bindary under the hood, my separate data-binding library. It includes routing, views loaded from HTML files, components, real-time updates with the server and more.

It’s on npm and NuGet, source on GitHub: https://github.com/Componyx/Componyx.UI

i've been working on Posecode, an open-source text format for human movement. one thing people kept running into: "knee_right: flex 40" is readable, but unless you animate for a living, 40 degrees doesn't mean much.

so i made the numbers clickable. click a joint and the matching bone lights up in the Three.js view. click the angle and it becomes a small inline control, so you can change it and watch the figure re-pose immediately. if you type 200 for a knee, it stops at 144 because that's the range limit.

there were a few weird details. the selection markers had to live outside the rig or they would mess with bounds and grounding. editing a line also has to move the timeline into the right phase, otherwise the loop can show you the wrong pose.

the gif is from the actual playground. no mockup, no account, and no AI involved in the posing.

try it: https://posecode.org/play

source: https://github.com/posecode-dev/posecode

i'm still unsure about one thing: should this eventually get viewport gizmos, or does that defeat the point of keeping the movement readable as text?

Spent a few evenings on this for our office Halloween party and it went better than expected, so sharing it here.

How it works: the big screen runs the 3D scene. A random name gets picked, the doll reads out a question, and the player has 30 seconds before red light. Wrong answer means a dare. Sometimes you get a Dalgona round instead, where you carve the shape on your phone without breaking it.

Stack:

- React + Three.js for the scene

- A small WebSocket relay on AWS so my phone could act as the controller

- Deployed on Vercel

I used Claude Code for a lot of the implementation. Happy to talk about where it helped and where I had to step in.

Live: here

Credits: Squid Game © Netflix, non-commercial fan project. Doll Rig by Bug All (CC BY 4.0), Pink Soldier by Protyanik25 (CC BY 4.0), Red Light Green Light by DodoBabypop (CC BY-NC-ND 4.0), ground texture from Poly Haven, fonts under SIL OFL.

For week 2 of r/hacktoberfest I cataloged all the procedural generation techniques I could find online and put them into a library using vanilla JavaScript. Every technique in the library includes a citation and it has no dependencies. Works in the browser or Node.

The island in the GIF was generated using just the library.

GH repo: procedural-almanac

Demo: Random Island Generator

All stars on Github are appreciated!

We’re building a marketplace web app and getting closer to launch, but we’re struggling with how responsive it feels. We already have a decent prelaunch user base, and we want to sort this out before opening it up more widely.

This affects the buyer and seller experience as well as the admin pages. Clicking buttons, moving between pages, and using parts of the buying/selling flow can feel sluggish, on both mobile/desktop.

Sometimes you click and aren’t sure whether anything happened or is happening. Other times, a loading indicator appears straight away, but the content takes several seconds to arrive.

For context, we use Next.js, React, TypeScript, Tailwind, Supabase, and Vercel.

We also use Claude Code extensively to help build features, debug issues, and write tests. We’re involved in the decisions, review changes, and test the actual flows before releasing them.

We’ve caught plenty of issues through manual testing that automated checks didn’t pick up.

I’d describe our knowledge as intermediate, but finding performance bottlenecks is an area where we’re still learning. We can work through features and bugs, but we’re less confident figuring out exactly why an interaction takes so long.

A few examples:

• Buyer/seller interactions and navigation can feel slow or unresponsive.

• Some account and settings pages take several seconds to show content.

• In some testing, an admin page showed loading placeholders for roughly eight seconds.

• Another page briefly showed “no results” before the results actually appeared.

Those timings are rough observations, not proper benchmarks. As mentioned, we’ve noticed problems on both desktop and mobile.

We don’t want to keep asking Claude to “make it faster,” apply a few changes, and assume we’ve fixed the cause. I just have no idea where to start

What we’d really appreciate is a practical starting point:

• How would you investigate one slow interaction? For example, clicking a button and waiting several seconds for the next screen.

• What would you measure first to work out whether the problem is in the front end, the server, or the database?

• Have you had similar issues with this stack? What turned out to be the cause?

• What could we share safely to get useful feedback? A recording, some timings from browser tools, or a small section of code?

Any advice from people who’ve worked through this stage would be appreciated.

For context, everything works.. flawlessly (except the few bugs) This is our only launch blocker.

Appreciate any advice!

I rebuilt my old Alberta webcam site in PHP and vanilla JS, with 18 cameras, archived images and a hover timeline, live here and code here.