Lúmina W | Software & Technology

Astro with static output and Tailwind CSS. Twelve components assemble the landing in a fixed order: hero, a fork between the two paths, problem, agitation, a phrase ribbon, solution, process, manifesto, why us, product, FAQ and contact. Each section has an anchor that matches the navigation bar and the footer.

Spanish by default at the root and English under /en, with both copies in typed dictionaries: the English dictionary requires the same keys as the Spanish one, so a missing key breaks the build. The products and contact pages have a translated route, and the legal pages keep the same name.

Contact form: the browser sends JSON to a Vercel Function that validates the fields (name, company, email, phone, need, stage and message), requires consent and silently drops whatever arrives through a hidden trap field. The need and stage values are fixed English codes, so an option is stored the same way in both languages.

The Function saves each request in Supabase and fills in the consent date, the origin, and the user agent on its own. It does not store the IP. If the email already exists, it returns a success response without creating another row, and still notifies the internal mailbox.

The internal notice goes out through Brevo and is best effort: if the email fails, the request is already stored. Storage only runs in Vercel production, so on previews the form returns 503 by design.

The requests table is a single one, shared with the TerraCore and OKroot landings, with a product column and a uniqueness constraint per product and email. It has row-level security on and no permissions for the public roles: only the Function can write.

Technical SEO: a JSON-LD graph with ProfessionalService, WebSite and WebPage, plus FAQPage on the FAQ, a self-referencing canonical, hreflang between es, en and x-default, a sitemap with alternates and a robots.txt that explicitly allows 21 AI crawlers, together with an llms.txt.

Analytics with consent: Google Analytics 4 loads only if the person accepts the cookie notice, and the decision is stored in local storage, with no first-party cookies. The notice does not block the page and appears after a little scrolling.

Performance and delivery: WebP images with explicit dimensions, fonts with swap, long-lived caching for hashed resources and images, and security headers. Deployment on Vercel is continuous.

Accessibility worked into the code: a skip link, visible focus, a label per field with announced errors and a success message with a status role, and respect for prefers-reduced-motion. A no-JavaScript fallback keeps the content that appears on scroll visible.

Quality: formatting, build, and secret scanning on every PR, with a branch flow across environments.

An editorial, sober system: straight edges (radii of 0, 2 and 4 pixels), one-pixel lines instead of shadows and a single stylesheet with the tokens.

Blue as the main color for links, tags and focus, and amber as a fill-only accent. When amber is text on a light background, a darker version is used to keep the contrast.

Cabinet Grotesk for headings and Switzer for body text, loaded from Fontshare with swap.

A light page with fixed dark surfaces (contact, footer, products and the navigation bar). There is no theme switch.

Calls to action carry text only, with no arrows or icons, and the project rule is not to use dashes as a connector in texts.

Next.js application (App Router, React and TypeScript) with Prisma on PostgreSQL in Supabase, and Tailwind CSS for styling. It replaced a previous Astro site with Decap CMS. The layout is dynamic on purpose: the CI build does not need a database.

Articles live in two ways: Markdown files in the repository (six today, three per language) that an importer loads into the database on every production build, and articles written by accounts inside the application. The importer creates or updates by language and slug, and never touches authorship, likes, saves or comments.

Publishing flow: an article goes through draft, pending, published or rejected. Any account can write and submit for review, only the administrator publishes directly, and editing a published article from an account other than hers sends it back to pending. The slug is frozen once published.

Bilingual: Spanish without a prefix and English under /en, with translated routes (articulos, categoria, cuenta) and a middleware that rewrites them to the internal routes. Each language is a Post row linked to the original, and likes, saves and comments are always anchored to the original.

Automatic translation: when an original is published, and only if a key is configured, a background task sends the title, description, body and tags to the Claude API as data, validates the response and stores the version in the other language. The administrator can retry it from the panel. File-based articles ship with their own translations.

Community: threaded comments of up to 2,000 characters, likes, saves, public profiles and following. Comment moderation is a local rule filter (blocked terms and a link cap) that calls no model: anything that matches is held as pending and the administrator approves or rejects it.

Newsletter with Brevo: one list per language, sign-up from the site and a test or campaign send from the admin panel, with Brevo's unsubscribe link. Reply, follow and save notifications also go out by email, in addition to inside the blog.

Accounts with email and password verified by email, plus Google, GitHub and LinkedIn when configured, and invitations that arrive with the email already verified. An external provider is accepted only if it confirms the email. An account is locked for 15 minutes after 5 failed attempts, and suspension and session invalidation are available from the panel.

Permissions are verified on the server on every request. Administration is restricted to a single account, protected from suspension and deletion.

Layered security: rate limits on credentials and sensitive operations, origin checks on routes that write, security headers, and user content sanitized before it renders.

Images: validated on the server, unsupported formats rejected, and converted to WebP with a size limit per use (cover, body, or avatar) before they are stored in object storage.

SEO and discovery: a dynamic sitemap with language alternates, robots with a separate group for AI crawlers, llms.txt, an RSS feed per language and JSON-LD (Organization, WebSite, BlogPosting, Blog, CollectionPage, ProfilePage and BreadcrumbList). Search uses case-insensitive matching over title, description, body, author and tags.

Analytics with consent: GA4 loads only if the person accepts and an identifier is configured, and the cross-domain link covers luminaw.co, terracoreapp.co and okroot.co.

Quality and delivery: 28 unit test files on pure logic, lint and build on every PR, secret scanning, and a branch flow across environments. In production, deployment applies the database changes and loads the articles.

A cover generator builds the 1200 by 630 WebP images, one per language, with a 150 KB cap, from a JSON spec and an SVG artwork.

The styles of the separately designed prototype were ported as is, and the theme lives in a single stylesheet with Tailwind CSS without the base reset.

Article with a reading progress bar, a table of contents and a share card, with the device's native menu as the route for Instagram.

1200 by 630 covers per language, generated from a spec and an SVG artwork, with a weight cap per image.

Accessibility worked into the code: a skip link, keyboard menus and a confirmation dialog with trapped focus. The contrast changes that would alter the design are pending a decision.

A language switch that remembers the choice in a cookie, and detection of the browser language on the first visit.