Description

This site is built for Scrabble players who want fast, reliable answers while they practice or prepare for games. It focuses on two everyday needs: checking whether a word is valid in official lists and finding playable words from a rack of letters. Both tasks are handled by a simple, direct interface so players can stay focused on the game rather than wrestling with a complex tool.

The dictionary side provides authoritative validation. When you submit a word, the server checks it against official word lists rather than relying on a client-side dataset. This protects the integrity of the source files and keeps the logic consistent across sessions. It also means the client only renders results that have already been validated on the server, which keeps the UI clean and predictable. The system does not guess or infer validity; it reports whether a word exists in the official lists and then provides helpful context around it.

The word finder is designed for practical play. You can input your rack and optionally include blanks using the "?" character. The solver returns valid words you can play, factoring in the blank tiles as wildcards. This feature is especially useful when you are studying anagrams, practicing rack management, or exploring high-probability plays. The focus is not on flashy output but on quick, usable results that match official lists.

Definitions are provided to make the results more meaningful, but they are not treated as the source of truth for validity. A separate definition lookup runs after validation and is cached so repeat lookups are fast. This prevents repeated external calls for common words and keeps the experience responsive. If a word is valid but the definition is not available, the word still appears as valid, and the UI can simply omit the definition. This separation keeps the core validation logic strict and avoids confusing a missing definition with an invalid word.

The project also includes word list pages for study and search engine entry points. These pages help users browse list-based content, revisit tricky words, and build familiarity with the official vocabulary. They are intentionally simple so the primary focus stays on the words themselves.

A typical session is straightforward. You type a single word to confirm its status, or you enter a rack to explore possible plays. Results are returned as a clean list that is easy to scan, so you can compare options without extra friction. The experience is built for quick checks during study sessions and for deeper exploration when you have time to learn new patterns.

On the technical side, the site is built with the Next.js App Router, using React Server Components by default. Server-only operations, such as word validation and list parsing, stay on the server. Client components are used only when interactivity is needed. This keeps data handling safe and performance consistent. TypeScript is used across the project to ensure predictable behavior and maintainable code, with strict typing enforced throughout.

The data layer uses PostgreSQL with Drizzle ORM. Drizzle provides a typed, schema-first approach and helps keep database interactions clean and explicit. Cached definitions are stored in the database so lookups are fast and consistent across sessions. The schema and migrations live in the db directory, and the connection setup is centralized to keep data access easy to audit and maintain.

The front end is styled with Tailwind CSS and shadcn/ui components, aiming for a clean, practical layout rather than heavy visual decoration. The UI is intended to be minimal and readable, making it easy to scan results and compare words quickly. Static assets live under public, and global styles are in app/globals.css.

The codebase is organized to keep concerns separated and easy to navigate. Routes live under app, reusable UI sections live in components, and domain helpers live in lib. This structure keeps the project approachable for future changes, whether that is adding a new word list page, extending definition sources, or refining the solver behavior.

Operationally, the app expects official word list files to exist on the server, placed in the data directory. This setup is deliberate: the lists should not be exposed in the client bundle. The server reads and validates against them, and only the results are sent to the client. This keeps the distribution of the lists controlled and helps ensure compliance and data safety.

This project is intentionally narrow in scope. It does not try to be a full Scrabble analytics suite or a move search engine. Its goal is to be a reliable dictionary and word finder that respects official lists, responds quickly, and remains easy to maintain. If you want a tool that is straightforward, server-validated, and built with modern Next.js practices, this site is designed to fit that need.