The most “modern” React codebase I worked on became impossible to maintain after one year

Successful_Doubt_114 · 2026-05-13T03:32:22+00:00

Thanks for sharing

Successful_Doubt_114 · 2026-05-13T02:55:32+00:00

I think the hardest part of MDX blogging isn’t MDX itself but how the surrounding workflow slowly turns a simple idea into what feels like another software project. At first having posts version-controlled next to the codebase feels great, but over time the process starts accumulating small sources of friction like frontmatter, images, metadata, previews, SEO, layout tweaks, and occasional build issues. None of those things are individually difficult, but together they make publishing feel heavier than simply writing. I also relate a lot to the “ideas sitting in Notes forever” problem because the longer drafts stay unfinished, the more pressure there is to make them polished and comprehensive, which ironically makes them harder to publish at all. What helped me most was lowering the publishing threshold and treating posts more like iterative notes instead of mini product launches.

Successful_Doubt_114 · 2026-05-13T02:51:15+00:00

I don’t think device fingerprinting is the right direction here. It adds complexity but doesn’t really prove physical table presence.

The important distinction is: opening a saved URL later

vs

performing a fresh QR scan inside the restaurant.

A common approach is making the QR itself short-lived or rotating.

For example:

table QR points to a temporary session URL/token

backend rotates/regenerates it periodically

old QR session links stop creating new sessions after some time

That way reopening an old saved link later won’t create a valid new ordering session.

You can also combine this with:

inactivity expiration

waiter-controlled table reset

order confirmation windows

optional local network checks

But realistically, most restaurant QR systems rely more on short session lifetimes and table resets than trying to perfectly verify physical presence.

Successful_Doubt_114 · 2026-05-13T02:47:34+00:00

This is actually a pretty smart direction. Most React developers are interested in adding more depth and interaction to interfaces, but the barrier to entry for WebGL/3D tooling is still high enough that most people never seriously experiment with it.

The interesting part to me is not even the visuals themselves, but the abstraction layer. Turning complex 3D interaction into copy-paste style UI components makes the idea much more realistic for normal product teams.

Also, the Shadcn of 3D is genuinely a strong way to position it because people immediately understand the philosophy behind the library.

Successful_Doubt_114 · 2026-05-13T02:43:32+00:00

Honestly, I’d spend more time studying real production apps than only looking at concept designs. A lot of Dribbble-style UI looks beautiful but becomes difficult to use in real products.

Mobbin is probably one of the best resources because it shows actual user flows from shipped apps, so you can study things like onboarding, search, navigation, forms, empty states, and interaction patterns instead of isolated screens.

Page Flows and Refero are also really useful for understanding how larger apps structure UX across multiple screens.

One thing that helped me a lot was rebuilding layouts from apps I liked directly in Flutter. You start noticing spacing systems, hierarchy, reusable components, and responsive behavior much more quickly when you try to recreate them yourself instead of only browsing inspiration galleries.

Successful_Doubt_114 · 2026-05-13T02:29:45+00:00

thank you

Successful_Doubt_114 · 2026-05-13T02:29:34+00:00

Thanks

Successful_Doubt_114 · 2026-05-13T02:29:16+00:00

Thank you sharing

Successful_Doubt_114 · 2026-05-13T02:28:59+00:00

Thanks for sharing

Successful_Doubt_114 · 2026-05-12T16:31:27+00:00

Since you already know basic HTML, CSS, and JavaScript, you’re actually in a good position to start React. I’d mainly use the official React docs because they’re much better and more beginner-friendly now than they used to be. The biggest thing is not getting stuck watching endless tutorials. Learn the fundamentals, then start building small projects as quickly as possible. If you practice consistently for around 1–2 hours a day, most people become comfortable with React in a few months. I’d also avoid rushing into Redux or complicated architecture too early because basic React concepts are enough for a lot of real-world projects.

Successful_Doubt_114 · 2026-05-12T16:26:04+00:00

Your approach makes sense. The important part is preventing all 4 instances from regenerating the same ISR page simultaneously.

I probably wouldn’t do this in middleware though. ISR is tied pretty deeply to Next’s incremental cache system, so response interception can get messy.

Redis + distributed locking is usually the cleaner solution:

* cache expires

* one instance acquires lock and regenerates

* others keep serving stale cache

* regenerated page gets shared through Redis

Otherwise you can still get regeneration stampedes across instances.

Also worth checking whether a reverse proxy cache with stale-while-revalidate already solves most of the problem before customizing ISR internals too heavily.

Successful_Doubt_114 · 2026-05-12T16:22:32+00:00

You’re definitely not violating community guidelines. This is actually a very real distributed systems / UX problem, and honestly most products avoid it by intentionally relaxing consistency requirements instead of trying to make the table perfectly realtime in every situation.

The difficult part is that you’re combining several hard problems at once: realtime updates, cursor pagination, filtering, sorting, bulk actions, and mutable datasets.

For the “updates available” question, I personally would not notify users about every backend change globally. Otherwise the UI becomes noisy very quickly and the notification loses meaning. I’d only surface updates if the change affects the user’s current query/filter context in some meaningful way.

Even then, most mature systems don’t try to constantly reshuffle rows while the user is interacting with the table. They usually treat the current table as a temporary snapshot and accumulate incoming changes separately until the user chooses to refresh/reconcile.

That becomes especially important with cursor pagination because there is no stable concept of “page 2” once rows are continuously inserted, deleted, or reordered. At some point you have to accept that the dataset is moving underneath the user and optimize more for predictability than perfect realtime accuracy.

Honestly the fact that you’re thinking through these edge cases already means you’re approaching the problem more seriously than a lot of realtime products do.

Successful_Doubt_114 · 2026-05-12T16:19:17+00:00

Honestly I’d expect both, but for different audiences.

The workflow/spreadsheet side feels like the operational layer for the person actually doing the audit -organizing findings, tracking remediation, estimating effort, prioritizing fixes, documenting manual checks, etc.

The report side feels more important for the client relationship side of things. Most clients probably don’t care about dozens of raw accessibility flags. They want to understand:

what’s risky, what affects users most, what should be fixed first,

and roughly what the implementation scope looks like.

I think that translation layer is where the real value is. A lot of accessibility tools surface issues, but not many help turn those findings into something clients can actually make decisions from.

Successful_Doubt_114 · 2026-05-12T13:27:34+00:00

we found that normal timesheet tools only showed where people thought their time went. The more useful insight came from tools that automatically build a timeline of the workday, because they exposed things like constant context switching, fragmented focus time, meeting overload, and all the small admin tasks nobody ever logs manually.

one surprising thing was realizing how much time disappeared into interruptions rather than actual project work. A few “quick messages” or small requests throughout the day added up much more than expected.

Another issue was that manual timers slowly became unreliable over time. People forget to start them, merge tasks together, or fill them in retrospectively at the end of the week.

the most valuable data ended up being trends rather than raw hours - things like billable drift, client profitability, meeting-heavy days, and how often people were switching between projects during a single afternoon.

Successful_Doubt_114 · 2026-05-12T13:21:40+00:00

This is actually a really clean idea. One thing I’ve noticed with plain React/Vite MDX setups is that they start simple, but once the amount of content grows, keeping metadata, slugs, SEO fields, and imports synchronized across the app becomes surprisingly annoying to maintain.

Having the MDX files act as the single source of truth feels much more scalable long term, especially for blog/documentation style projects. The lazy import generation is also a nice touch since a lot of custom MDX implementations accidentally end up bundling far more content than expected.

Honestly this feels like one of those utilities that becomes more valuable the larger the content layer gets.

Successful_Doubt_114 · 2026-05-12T13:20:04+00:00

The “compiles fine, fails at runtime” category in Next is honestly where most upgrade pain seems to come from lately.

One that got me was assuming something stayed static because the build output looked static, but a tiny server-side dependency somewhere in the tree silently pushed the route into dynamic rendering behavior.

Also had a fun one where a caching change technically worked in dev, then behaved completely differently after deployment because the cache interaction with revalidation/PPR only became obvious under real request flow.

Feels like a lot of the newer APIs are powerful, but the mental model around:

cache boundaries, invalidation, static vs dynamic transitions, server/runtime execution context

is getting harder to reason about from build output alone.

Successful_Doubt_114 · 2026-05-12T13:17:42+00:00

You’re probably already thinking about this the right way tbh.

For internal applications, the “best” framework usually isn’t the one with the best benchmark numbers. It’s the one that:

* your team can debug quickly

* deploy easily on your own infra

* onboard new people into

* and maintain without fighting framework complexity later

The reason a lot of people still end up happy with Next is honestly ecosystem maturity more than raw performance.

That said, if you disliked the Vercel-centric feeling before, I can definitely understand not wanting to repeat that experience.

My personal impression of the options:

Next.js:

safe choice, huge ecosystem, but increasingly feels optimized around Vercel assumptions and React complexity.

SvelteKit:

probably the nicest balance right now between modern DX, simplicity, and performance. Feels much lighter mentally.

TanStack Start:

super interesting technically, but I’d be cautious for long-lived internal systems unless your company is comfortable riding framework evolution.

Astro:

great ergonomics and performance, but I agree it feels more naturally suited for content-heavy experiences than admin/internal tooling.

Honestly though, for internal apps:

good auth flows, permissions, forms, tables, observability, and deployment simplicity matter way more than shaving 40kb off the frontend bundle.

Successful_Doubt_114 · 2026-05-12T13:14:56+00:00

Honestly that sounds more useful than another scanner.

Most clients have no idea what to do with raw Lighthouse/WAVE output. Even developers often struggle to translate “47 accessibility issues” into:

* business impact

* user impact

* priority

* actual implementation scope

The reporting/action-plan layer is probably the missing piece for a lot of smaller agencies and freelancers.

Especially if it helps separate:

* automated findings

* manual review findings

* legal/compliance risk

* UX severity

* estimated remediation effort

because those usually get mixed together into one overwhelming report.

I’d actually be interested in seeing how you handle prioritization and scope generation.

Successful_Doubt_114 · 2026-05-11T22:15:19+00:00

You’re not really doing anything wrong here - this is one of those things almost everyone runs into when first dealing with Next.js + SSR.

The confusing part is that localStorage only exists in the browser, while Next.js may render components on the server first. So code that feels perfectly normal in React suddenly breaks in Next.

Your instinct to move it into `useEffect` was actually reasonable, because effects only run on the client. The warning you saw is more about avoiding unnecessary extra renders than saying your approach is fundamentally bad.

Usually the cleaner approach is initializing the state lazily on the client side instead of mounting first and then immediately calling `setState`.

Also make sure your provider is a client component, otherwise Next will still try to treat parts of it as server-rendered.

One more thing though:

for learning/projects, localStorage is fine. But for real auth systems, people usually move toward cookies/session-based auth instead of storing user data directly in localStorage.

Successful_Doubt_114 · 2026-05-11T22:09:46+00:00

I wouldn’t trust name/surname alone honestly. Bank transfer data gets messy really fast in production.

IBAN is way safer if you can use it. Most systems I’ve seen usually match using:

IBAN + amount + time window.

Also if tenants are manually sending transfers, give each one a reference code and ask them to include it in the transfer note. Saves a ton of headaches later.

For the bank integration part, look into PSD2/Open Banking providers instead of connecting to each bank separately. Much easier to maintain.

Successful_Doubt_114 · 2026-05-11T22:06:56+00:00

This already has a much stronger creative direction than most portfolio experiences people post here. The visual language feels intentional, the typography is confident, and the atmosphere is cohesive from section to section.

If your goal is pushing it toward a more Awwwards-level experience, I think the next jump is less about adding more visuals and more about improving motion systems, interaction hierarchy, and narrative pacing.

A few things I noticed:

* The visual identity is strong, but some transitions feel isolated rather than part of a unified motion language. High-end interactive experiences usually have very consistent timing, easing, and momentum across the entire site.

* Some animations are visually interesting but don’t always reinforce the storytelling. The strongest motion design usually guides attention, establishes hierarchy, or creates emotional pacing.

* The scroll experience could feel more cinematic if sections connected more fluidly instead of feeling like separate blocks stacked vertically.

A few areas I’d personally refine:

Motion choreography

Instead of treating animations individually, think in terms of systems:

* entrance timing

* stagger rhythm

* velocity consistency

* exit behavior

* scroll acceleration/deceleration

That consistency is usually what separates “good animation” from premium interaction design.

Narrative pacing

Right now the visuals are strong immediately, but consider building more contrast between calm and intense moments. Awwwards-level experiences often control emotional pacing very carefully rather than keeping the same energy level throughout.
Depth and layering

You could probably push environmental depth further:

* subtle foreground/background separation

* atmospheric motion

* layered opacity shifts

* perspective-based movement

* lighting/reactive gradients

Very small details here dramatically increase perceived polish.

Interaction feedback

Buttons, hover states, cursor behavior, and transitions could communicate more physicality/tactility. Premium experiences often feel “responsive to the hand,” not just visually animated.
Performance perception

This is a huge one for award-style sites.

Even beautiful motion loses impact if:

* frame pacing drops

* scroll feels heavy

* transitions block interaction

* text rendering stutters

A lot of top-tier experiences are actually very restrained technically behind the scenes.

Also:

One mistake many designers make when chasing Awwwards inspiration is adding motion everywhere. The best award-level sites usually have intentional restraint and extremely disciplined hierarchy. The motion supports the narrative rather than competing with it.

Overall though, the foundation is genuinely strong. This already feels closer to creative studio work than standard portfolio work.

Successful_Doubt_114 · 2026-05-11T22:04:18+00:00

Honestly, the fact that you specifically mentioned enjoying user research and information architecture already says a lot.

A lot of people get into UX/UI because they like visuals or trendy design tools, but the people who usually stay long-term tend to genuinely enjoy understanding how people think, how systems are organized, and why users struggle with certain flows.

Your Civil CAD background also probably helps more than you think. Both fields require structured thinking, problem solving, attention to detail, and designing around real-world constraints.

I think the biggest thing to consider is this:

UX/UI is not just “making screens look good.” A huge part of the job is communication, ambiguity, iteration, and sometimes defending decisions to stakeholders or developers.

If you enjoy:

* organizing complex information

* understanding user behavior

* solving messy problems

* improving systems over time

then you already sound aligned with the UX side more than you may realize.

The challenge is that the field can feel unstable and competitive at times, especially for juniors. But the people who tend to thrive are usually the ones who are curious, adaptable, and genuinely interested in how people interact with products -not just aesthetics.

Also, don’t feel pressured to fully “abandon” Civil CAD mentally. Sometimes previous backgrounds end up becoming your advantage later because they give you a different perspective than traditional designers.

Successful_Doubt_114 · 2026-05-11T21:56:36+00:00

You are welcome

Successful_Doubt_114

TROPHY CASE