agasocial/video-generator-microsaas
Reviewed against Rams quality heuristics: accessibility, color, typography, spacing, components, motion, UX, and craft.
30 files reviewed·July 31, 2026
Low
Design risk in this codebase.
More findings
Verdict
Auth flow engineering is solid, but every quiet moment leaks: raw error codes, silent waits, English text in translated skeletons. Fix the user-facing error message first, it's the fastest way to stop confusing and alarming people mid-flow.
Files Rams reviewed
app/[locale]/auth/callback/page.tsx
app/[locale]/auth/error/page.tsx
app/[locale]/auth/login/page.tsx
app/[locale]/auth/reset-password/page.tsx
app/[locale]/auth/sign-up-success/page.tsx
app/[locale]/auth/sign-up/page.tsx
app/[locale]/credits/page.tsx
app/[locale]/generate/page.tsx
app/[locale]/layout.tsx
app/[locale]/profile/page.tsx
app/auth/error/page.tsx
app/auth/login/page.tsx
app/auth/sign-up-success/page.tsx
app/auth/sign-up/page.tsx
app/credits/page.tsx
app/layout.tsx
app/profile/page.tsx
app/page.tsx
app/[locale]/page.tsx
app/globals.css
components/credit-packages.tsx
components/image-cropper.tsx
components/language-switcher.tsx
components/navigation.tsx
components/payment-success-handler.tsx
components/stripe-buy-button.tsx
components/theme-injector.tsx
components/theme-selector.tsx
components/ui/accordion.tsx
components/ui/alert-dialog.tsx
Components
app/[locale]/auth/login/page.tsx:254
Login page's loading skeleton flashes English text for every locale
In app/[locale]/auth/login/page.tsx, the Suspense fallback hardcodes `<CardTitle className="text-2xl">Sign in</CardTitle>` and "Enter your credentials to access your account", while the loaded LoginForm uses `t('signIn')` and `t('signInDesc')`. Non-English users briefly see English copy before the translated form mounts.
Why it matters
Every page load flashes the wrong language for non-English users, which reads as a broken or half-translated app rather than a deliberate loading state.
Fix
Pull the fallback strings from the same translation keys used in the loaded form.
<CardTitle className="text-2xl">Sign in</CardTitle>
<CardDescription>
Enter your credentials to access your account
</CardDescription><CardTitle className="text-2xl">{t('signIn')}</CardTitle>
<CardDescription>
{t('signInDesc')}
</CardDescription>app/[locale]/auth/login/page.tsx:209
Google button duplicates its own variant's default styling
The Google sign-in Button in app/[locale]/auth/login/page.tsx sets `variant="default"` and then adds `className="w-full bg-primary text-primary-foreground hover:bg-primary/90"`, which is the same background, text color, and hover state the default variant already provides.
Why it matters
If the default button token changes later (color, hover opacity), this instance won't pick it up because the values are pinned locally, causing silent visual drift between this button and every other default button in the app.
Fix
Remove the redundant color classes and let the default variant supply styling, keeping only the layout override (w-full).
variant="default"
className="w-full bg-primary text-primary-foreground hover:bg-primary/90"variant="default"
className="w-full"Color
app/[locale]/auth/login/page.tsx:150
Email field's white background breaks form field consistency
In app/[locale]/auth/login/page.tsx, the email Input uses `className={error ? "border-destructive border" : "border bg-white text-primary hover:bg-white/80"}` while the adjacent password Input two fields below only uses `className={error ? "border-destructive border" : "border"}`. The email field gets a hardcoded white fill and hover state the password field doesn't have.
Why it matters
Two inputs in the same form render with visibly different fills, which reads as a bug rather than a design choice and undermines trust in the form right before a sign-in submission.
Fix
Drop the one-off bg-white/hover override and let both inputs share the same default input styling.
className={error ? "border-destructive border" : "border bg-white text-primary hover:bg-white/80"}className={error ? "border-destructive border" : "border"}Get this score on every PR.
Rams reviews each pull request on your repo and posts inline one-click fixes — about a minute per review.
Install Rams freeMotion
app/[locale]/auth/callback/page.tsx:63
Auth callback shows static text with no progress feedback
The callback screen at app/[locale]/auth/callback/page.tsx renders only `<span>{t('signingIn')}</span>` inside a centered flex container while the async session exchange runs in the background. There is no spinner, skeleton, or animated indicator, so the screen looks frozen during the redirect wait.
Why it matters
Users can't tell if the app is working or has stalled, and on a slow network they may reload or navigate away, aborting the auth flow mid-redirect.
Fix
Pair the loading text with a visible spinner so async work reads as in-progress rather than stuck.
<div className="flex items-center justify-center min-h-screen">
<span>{t('signingIn')}</span>
</div><div className="flex items-center justify-center min-h-screen gap-2">
<Loader2 className="h-4 w-4 animate-spin" />
<span>{t('signingIn')}</span>
</div>UX
app/[locale]/auth/error/page.tsx:29
Raw error code shown to users with no explanation of what happened
On app/[locale]/auth/error/page.tsx, when a query error is present the description renders `${tGenerate("errorLabel")} ${error}`, a raw code like `callback_error` with no plain-language explanation. The only recovery action is a "Sign in" button; there's no retry, support link, or context for what went wrong.
Why it matters
Users hitting an OAuth failure see a code they don't understand and one path forward, so anyone whose error isn't fixed by re-signing-in (expired session, blocked provider) has no next step.
Fix
Map known error codes to human-readable messages and keep the raw code as secondary detail, not the primary message.
{error ? `${tGenerate("errorLabel")} ${error}` : tGenerate("authenticationErrorDesc")}{error ? tGenerate(`errorMessages.${error}`, { fallback: tGenerate("authenticationErrorDesc") }) : tGenerate("authenticationErrorDesc")}Accessibility
Typography
Spacing
Craft
Working well
- Both submit buttons ("signInButton" and the Google button) disable during isLoading/isGoogleLoading and swap in a Loader2 spinner with translated loading text, giving clear async feedback and preventing double-submit.
- Wrapping the OAuth callback logic in try/catch with a fallback redirect to the login page and an error query param gives users a recovery path instead of a stuck blank screen when the session exchange fails.
- Using asChild on the Button wrapping the sign-in Link keeps the action a single semantic anchor with button styling instead of nesting two interactive elements.
Scored July 31, 2026 with Rams Engine v0.0.3 · Engine changelog
This page is an automated design review of agasocial/video-generator-microsaas’s UI code: 30 files read against 291 versioned rules covering accessibility, color, typography, spacing, components, UX, motion, and craft. The score is out of 100; any confirmed critical issue caps it at 59.
More design scores
Score your own repo.
Free on public repos, no account. The same engine that scored this page reads your UI code and mints a score page like this one.
Public repos only. The full engine reviews the UI code and mints a public score page — we email you the link too. Already-scored repos open instantly.
