Frontend Developer (React / Next.js)

Frontend Developer (React / Next.js) at YesAstrology

YesAstrology is hiring a Frontend Developer (React / Next.js) for a full-time, fully remote position open to candidates worldwide within the Engineering department. The role centers on building ultra-fast, accessible, and reactive web experiences using Next.js App Router, React 19, and TypeScript, with direct ownership of the interfaces behind our calculation tools, report readers, and interactive features. Candidates should bring at least 2+ years of production experience with modern React, Next.js, and TypeScript, alongside proficiency in Tailwind CSS and modern responsive layout patterns.

Day to day, you will develop and maintain responsive, high-performance web components using the Next.js App Router and TypeScript, and build the interactive chart calculation widgets, dynamic input forms, and data visualizations that sit at the heart of the platform. A significant part of the work is performance engineering: optimizing Core Web Vitals (LCP, INP, CLS) and server-side rendering latency across global edge networks. You will also implement accessible, semantic markup following WCAG 2.1 AA guidelines and write robust unit and integration tests to ensure reliable, regression-free releases.

The stack is Next.js 15, React 19, TypeScript, Tailwind CSS, Supabase (PostgreSQL), and Vercel edge deployment. Our workflow runs on Git feature branches, pull request reviews, strict ESLint and TypeScript gates, and automated test pipelines. Beyond the technical requirements, we look for a solid understanding of web performance optimization, caching strategies, and client/server boundaries, plus experience maintaining clean, modular, reusable code and familiarity with Git workflow, code reviews, and continuous integration. The engineering team operates asynchronously with high autonomy and flexible working hours, so you can work from any time zone.

If this sounds like your kind of craft, explore more about the platform on our home page and consider applying to join a remote team building fast, accessible astrology experiences at global scale.

Role Overview and Development Responsibilities

The Frontend Developer (React / Next.js) at YesAstrology is a full-time, fully remote engineering position responsible for building and maintaining high-performance, accessible, and responsive user interfaces for the platform's calculation tools, report readers, and interactive features. The role sits within the Engineering department and operates asynchronously across any time zone, giving the developer high autonomy and flexible working hours. Day to day, this means shipping modular components on a modern stack of Next.js 15, React 19, TypeScript, and Tailwind CSS, with Supabase (PostgreSQL) on the data side and Vercel edge deployment for delivery.

The core mandate is speed and accessibility in equal measure. The developer develops and maintains responsive, high-performance web components using the Next.js App Router and TypeScript, and builds the interactive chart calculation widgets, dynamic input forms, and data visualizations that sit at the heart of the astrology experience. Because those widgets accept birth data and render computed charts, every millisecond of input latency and every layout shift is felt directly by the user. The role therefore owns Core Web Vitals optimization — LCP, INP, and CLS — alongside server-side rendering latency across global edge networks, and implements accessible, semantic markup following WCAG 2.1 AA guidelines so that chart tables, form labels, and interactive controls remain usable with assistive technology.

How the Work Maps to the Product

Consider a concrete example: a user enters a birth date, time, and place into a chart form. The frontend must validate the input, handle the case where birth time is unknown, and render the resulting planetary positions and house cusps without blocking the main thread. Whether the chart engine resolves house cusps via Placidus, Whole Sign, or Equal House, the interface has to present those results clearly — labeling the Midheaven degree, distinguishing the 10th house career signature from the 6th house daily-work signature, and flagging an exact conjunction or square so the reader understands the aspect at a glance. The developer builds the components that make that legible, and optimizes the rendering path so a heavy wheel visualization never degrades LCP or causes CLS as data streams in.

Quality is enforced through process rather than hope. The team works on Git feature branches with pull-request reviews, strict ESLint and TypeScript gates, and automated test pipelines; the developer writes robust unit and integration tests to ensure reliable, regression-free releases. Candidates should bring 2+ years of production experience with modern React, Next.js, and TypeScript, proficiency with Tailwind CSS and CSS architecture, a solid grasp of caching strategies and client/server boundaries, and familiarity with continuous integration. To see the kind of interfaces this role shapes, explore the platform's astrology tools firsthand.

Frontend Architecture and Component Development

Frontend architecture at YesAstrology is the discipline of turning astrological calculation output into modular, reusable React components that stay fast and accessible at global scale. The Frontend Developer (React / Next.js) owns this layer: chart calculation widgets, dynamic birth-data input forms, report readers, and the interactive features that sit between raw ephemeris data and a clear reading. The stack is fixed — Next.js 15, React 19, TypeScript, Tailwind CSS, Supabase (PostgreSQL) on the data side, and Vercel edge deployment for delivery — so architectural decisions are made once and reused across every tool on the platform.

Component boundaries follow the shape of the astrology itself. A natal chart wheel is not one monolith but a composition: a zodiac ring, a house-cusp layer, a planetary glyph layer, and an aspect grid. Each layer receives typed props — sign, degree, house number, aspect type — so the same PlanetGlyph component renders a Sun in Leo at 14° in a natal chart and a transiting Saturn in the same sign without duplication. When the chart engine resolves house cusps via Placidus, Whole Sign, or Equal House, the interface must label the Midheaven degree explicitly and visually separate the 10th house career signature from the 6th house daily-work signature, because those two houses are frequently confused by readers. A well-factored component tree makes that distinction a prop, not a rewrite.

Accessibility is treated as an architectural constraint rather than a final pass. Semantic markup following WCAG 2.1 AA guidelines means the aspect grid is a real table with headers, the birth-date and birth-time inputs carry proper labels and error associations, and the chart wheel exposes a text alternative that lists planetary positions in reading order. Screen reader users and keyboard navigators must be able to complete a full chart request without touching a mouse. Tailwind CSS handles the responsive layout patterns, but the underlying CSS architecture keeps spacing, typographic scale, and color tokens centralized so a change to the report reader propagates consistently.

Quality is enforced through process: Git feature branches, pull-request reviews, strict ESLint and TypeScript gates, and automated test pipelines. Unit tests cover pure formatting logic — degree-to-sign conversion, orb calculations for a conjunction versus a square — while integration tests verify that a form submission with an unknown birth time still renders a coherent chart. Candidates should bring 2+ years of production experience with modern React, Next.js, and TypeScript, plus a solid grasp of caching strategies and client/server boundaries. To see the interfaces this architecture produces, browse the platform's astrology reports firsthand.

React and Next.js Application Development

React and Next.js application development at YesAstrology means shipping interactive chart tools on Next.js 15 App Router and React 19, with TypeScript enforcing the contract between calculation data and rendered UI. The developer builds the chart calculation widgets, dynamic input forms, and data visualizations that visitors use to request a natal chart reading, then optimizes the rendering path so those tools meet Core Web Vitals targets — LCP, INP, and CLS — across global edge networks. Server-side rendering latency is measured and tuned, not assumed.

The App Router shapes how work is split. Server Components render the static shell of a report reader — the interpretation text, the sign and house headings, the planetary position tables — while Client Components handle the interactive parts: the birth-data form, the chart wheel hover states, the aspect filter toggles. Keeping that boundary clean is a core requirement, because a heavy wheel visualization that leaks into the server render degrades LCP, and a form that re-renders on every keystroke without memoization inflates INP. Caching strategies at the edge determine whether a returning visitor sees a report instantly or waits on a round trip to Supabase.

Concrete product logic drives the component design. When a visitor submits a birth date, time, and place, the frontend validates the input, handles the case where birth time is unknown, and renders planetary positions and house cusps without blocking the main thread. If the chart engine defaults to a solar-noon chart when the birth time is missing, the interface must say so plainly, because an unknown rising sign changes the entire house structure — a Capricorn Midheaven with Saturn in the 10th reads very differently from an Aries Midheaven with Mars in the 2nd. Exact aspects deserve visual emphasis: an applying conjunction between the Moon and Pluto should be flagged distinctly from a wide trine, and the UI should make that legibility immediate rather than buried in a data table.

The workflow runs on Git feature branches, pull-request reviews, strict ESLint and TypeScript gates, and automated test pipelines, with robust unit and integration tests guarding against regressions. The position is full-time and fully remote, open to candidates worldwide, and the Engineering team works asynchronously with high autonomy and flexible hours across any time zone. Required experience is 2+ years of production work with modern React, Next.js, and TypeScript, proficiency with Tailwind CSS and CSS architecture, and familiarity with continuous integration. To understand the wider product surface these applications serve, explore the platform's astrology products.

Responsive Design and Cross-Browser Compatibility

Responsive design and cross-browser compatibility at YesAstrology mean that every chart calculation widget, birth-data form, and report reader renders correctly and remains fully operable from a small phone screen to a wide desktop display, across modern browsers, using Tailwind CSS and modern responsive layout patterns on Next.js 15 and React 19. The Frontend Developer (React / Next.js) treats layout integrity as a product requirement: a visitor entering birth details must see the same labeled fields, the same planetary position tables, and the same aspect grid regardless of device or browser engine.

The hardest responsive problem is the natal chart wheel. It is not one element but a composition — a zodiac ring, a house-cusp layer, a planetary glyph layer, and an aspect grid — and each layer must scale without collapsing glyphs into illegible clusters or clipping the Midheaven degree label. On narrow viewports the wheel typically reflows into a stacked reading order, while the aspect grid becomes a real table with headers so that a conjunction between the Moon and Pluto stays distinguishable from a wide trine. Because the chart engine may resolve house cusps via Placidus, Whole Sign, or Equal House, the interface must also keep the 10th house career signature visually separate from the 6th house daily-work signature at every breakpoint, since those two houses are frequently confused by readers.

Cross-browser compatibility is enforced rather than assumed. Semantic markup following WCAG 2.1 AA guidelines — proper labels and error associations on birth-date and birth-time inputs, a text alternative on the chart wheel listing planetary positions in reading order — behaves consistently across engines, and keyboard navigators must be able to complete a full chart request without a mouse. Tailwind CSS handles the responsive layout patterns, while the underlying CSS architecture keeps spacing, typographic scale, and color tokens centralized so a single change to the report reader propagates consistently instead of drifting per component.

Verification runs through the same pipeline as the rest of the codebase: Git feature branches, pull-request reviews, strict ESLint and TypeScript gates, and automated test pipelines. Integration tests confirm that a form submission with an unknown birth time still renders a coherent, responsive chart, and that a solar-noon default is stated plainly in the UI, because an unknown rising sign changes the entire house structure. Candidates should bring 2+ years of production experience with modern React, Next.js, and TypeScript plus proficiency with Tailwind CSS and CSS architecture; to see the interfaces this work produces, browse the YesAstrology blog.

Website Performance and Core Web Vitals Optimization

Website performance and Core Web Vitals optimization at YesAstrology means treating LCP, INP, and CLS as product requirements, not afterthoughts: the Frontend Developer (React / Next.js) tunes server-side rendering latency across global edge networks on Vercel so that a chart request returns a usable page quickly, and keeps interaction latency low enough that birth-data forms respond instantly on any device. The stack is fixed — Next.js 15 App Router, React 19, TypeScript, Tailwind CSS, and Supabase (PostgreSQL) on the data side — so performance decisions are made once and reused across every tool.

The App Router shapes where the budget is spent. Server Components render the static shell of a report reader — interpretation text, sign and house headings, planetary position tables — while Client Components handle the interactive parts: the birth-data form, chart wheel hover states, and aspect filter toggles. Keeping that boundary clean is a core requirement, because a heavy wheel visualization that leaks into the server render degrades LCP, and a form that re-renders on every keystroke without memoization inflates INP. Caching strategies at the edge determine whether a returning visitor sees a report instantly or waits on a round trip to Supabase.

Concrete product logic drives the optimization work. When a visitor submits a birth date, time, and place, the frontend validates the input, handles the case where birth time is unknown, and renders planetary positions and house cusps without blocking the main thread. If the chart engine defaults to a solar-noon chart when the birth time is missing, the interface must say so plainly, because an unknown rising sign changes the entire house structure — a Capricorn Midheaven with Saturn in the 10th reads very differently from an Aries Midheaven with Mars in the 2nd. Exact aspects deserve visual emphasis: an applying conjunction between the Moon and Pluto should be flagged distinctly from a wide trine, and that emphasis must arrive without causing layout shift as data streams in.

Quality is guarded by Git feature branches, pull-request reviews, strict ESLint and TypeScript gates, and automated test pipelines, with unit tests covering pure formatting logic such as degree-to-sign conversion and orb calculations, and integration tests verifying that an unknown-birth-time submission still renders a coherent chart. The position is full-time and fully remote, open to candidates worldwide, and the Engineering team works asynchronously with high autonomy and flexible hours across any time zone. Required experience is 2+ years of production work with modern React, Next.js, and TypeScript, proficiency with Tailwind CSS and CSS architecture, and a solid grasp of caching strategies and client/server boundaries.

API Integration and Backend Collaboration

API integration at YesAstrology means the Frontend Developer (React / Next.js) consumes calculation and content data from Supabase (PostgreSQL) through clean, typed contracts, keeping the client/server boundary explicit so that chart widgets render real ephemeris output without leaking heavy computation into the browser. The stack is fixed — Next.js 15 App Router, React 19, TypeScript, Tailwind CSS, Supabase on the data side, and Vercel edge deployment — so integration patterns are decided once and reused across every tool on the platform.

The App Router shapes how that collaboration is structured. Server Components fetch and render the static shell of a report reader — interpretation text, sign and house headings, planetary position tables — while Client Components handle the interactive parts: the birth-data form, chart wheel hover states, and aspect filter toggles. Keeping that boundary clean is a core requirement, because a heavy wheel visualization that leaks into the server render degrades LCP, and a form that re-renders on every keystroke without memoization inflates INP. Caching strategies at the edge determine whether a returning visitor sees a report instantly or waits on a round trip to Supabase, so the frontend developer works directly with backend colleagues on cache invalidation rules, response shapes, and fallback behavior when a request fails.

Concrete product logic drives the integration work. When a visitor submits a birth date, time, and place, the frontend validates the input, handles the case where birth time is unknown, and renders planetary positions and house cusps without blocking the main thread. If the chart engine defaults to a solar-noon chart when the birth time is missing, the interface must say so plainly, because an unknown rising sign changes the entire house structure — a Capricorn Midheaven with Saturn in the 10th reads very differently from an Aries Midheaven with Mars in the 2nd. Whether the backend resolves house cusps via Placidus, Whole Sign, or Equal House, the response must carry the method and the Midheaven degree explicitly, and the frontend must keep the 10th house career signature visually separate from the 6th house daily-work signature, since readers frequently confuse the two.

Quality is guarded by Git feature branches, pull-request reviews, strict ESLint and TypeScript gates, and automated test pipelines. Unit tests cover pure formatting logic such as degree-to-sign conversion and orb calculations for a conjunction versus a square, while integration tests verify that an unknown-birth-time submission still renders a coherent chart against mocked API responses. The position is full-time and fully remote, open to candidates worldwide, and the Engineering team works asynchronously with high autonomy and flexible hours across any time zone — which makes written API contracts and precise documentation as important as the code itself.

Required Skills, Experience, and Qualifications

YesAstrology requires at least 2+ years of production experience with modern React, Next.js, and TypeScript, plus proficiency with Tailwind CSS, modern responsive layout patterns, and CSS architecture for this full-time, fully remote Frontend Developer (React / Next.js) position open to candidates worldwide. Beyond framework fluency, candidates need a solid understanding of web performance optimization, caching strategies, and client/server boundaries, experience writing automated tests and maintaining clean, modular, reusable code, and familiarity with Git workflows, code reviews, and continuous integration pipelines.

These requirements map directly onto the product. Component boundaries follow the shape of the astrology itself: a natal chart wheel is not one monolith but a composition of a zodiac ring, a house-cusp layer, a planetary glyph layer, and an aspect grid, each receiving typed props — sign, degree, house number, aspect type — so the same glyph component renders a Sun in Leo at 14° in a natal chart and a transiting Saturn in the same sign without duplication. When the chart engine resolves house cusps via Placidus, Whole Sign, or Equal House, the interface must label the Midheaven degree explicitly and visually separate the 10th house career signature from the 6th house daily-work signature. A well-factored component tree makes that distinction a prop, not a rewrite.

Accessibility is treated as an architectural constraint rather than a final pass. Semantic markup following WCAG 2.1 AA guidelines means the aspect grid is a real table with headers, the birth-date and birth-time inputs carry proper labels and error associations, and the chart wheel exposes a text alternative that lists planetary positions in reading order. Screen reader users and keyboard navigators must be able to complete a full chart request without touching a mouse. Tailwind CSS handles the responsive layout patterns, while the underlying CSS architecture keeps spacing, typographic scale, and color tokens centralized so a change to the report reader propagates consistently.

Performance work is measured, not assumed. The developer owns Core Web Vitals — LCP, INP, and CLS — alongside server-side rendering latency across global edge networks, and flags exact aspects with visual emphasis, so an applying conjunction between the Moon and Pluto reads distinctly from a wide trine without causing layout shift as data streams in. Verification runs through Git feature branches, pull-request reviews, strict ESLint and TypeScript gates, and automated test pipelines, with integration tests confirming that a solar-noon default is stated plainly in the UI. To see the wider product surface these skills serve, explore the platform's astrology products.

How to Apply for the Frontend Developer Position

To apply for the Frontend Developer (React / Next.js) position at YesAstrology, submit your application through the official YesAstrology careers channel for this published listing, including your CV and a short note describing your production experience with modern React, Next.js, and TypeScript. The role is full-time and fully remote, open to candidates worldwide, and sits within the Engineering department. Because the team works asynchronously with high autonomy and flexible hours, your written application is the first real sample of how you communicate — so make it specific, concise, and technically grounded rather than generic.

Your application should demonstrate the exact competencies the role requires: 2+ years of production experience with modern React, Next.js, and TypeScript; proficiency with Tailwind CSS, modern responsive layout patterns, and CSS architecture; a solid understanding of web performance optimization, caching strategies, and client/server boundaries; experience writing automated tests and maintaining clean, modular, reusable code; and familiarity with Git workflows, code reviews, and continuous integration pipelines. The strongest applications connect those skills to concrete interface problems — for instance, how you kept a heavy interactive visualization from degrading LCP, or how you structured a form so that an unknown birth time is handled and disclosed plainly in the UI, since an unknown rising sign changes the entire house structure and a Capricorn Midheaven with Saturn in the 10th reads very differently from an Aries Midheaven with Mars in the 2nd.

Expect the evaluation to mirror how the team actually builds. The workflow runs on Git feature branches, pull-request reviews, strict ESLint and TypeScript gates, and automated test pipelines, so a code sample or take-home exercise is likely to be judged on component factoring, typed props, accessibility, and test coverage rather than visual polish alone. Show how you would decompose a natal chart wheel into a zodiac ring, a house-cusp layer, a planetary glyph layer, and an aspect grid, each receiving typed props such as sign, degree, house number, and aspect type — and how you would keep the 10th house career signature visually separate from the 6th house daily-work signature when the chart engine resolves cusps via Placidus, Whole Sign, or Equal House.

Before you submit, spend time inside the product you would be building. Request a chart, notice where input latency or layout shift appears, and check whether the aspect grid is a real table with headers and whether the chart wheel exposes a text alternative listing planetary positions in reading order — the WCAG 2.1 AA standard the team treats as an architectural constraint. If your background fits this way of working, apply and state clearly which parts of the stack — Next.js 15 App Router, React 19, TypeScript, Tailwind CSS, Supabase (PostgreSQL), or Vercel edge deployment — you have shipped to production and at what scale.