There is an active production site with a product catalog, model cards, and informational pages.
Frontend stack:
— Next.js;
— React;
— TypeScript;
— existing component system;
— staging and production environments.
There is an approved visual direction and design for the new homepage. It is necessary to implement it into the existing project, adapt it for desktop/tablet/mobile, and bring all main types of pages on the site to a unified updated style.
A complete redesign of the product and changes to business logic are not required.
MANDATORY SCOPE
1. New homepage
— implement the homepage according to the provided design;
— maintain existing functionality, links, and routing;
— correctly connect approved sections and CTAs;
— use existing data and APIs;
— ensure correct display of dynamic content.
Main types of sections:
— header/navigation;
— hero;
— informational blocks;
— model/offering cards;
— analytical or market insight blocks;
— CTA sections;
— footer.
The exact composition of sections will be provided to the selected performer along with the layout.
2. Responsive
It is necessary to implement:
— desktop;
— tablet;
— mobile;
— intermediate resolutions;
— correct behavior of grids, cards, menus, buttons, and typography;
— absence of horizontal scrolling and visual conflicts.
3. Typography and general styles
— implement new approved fonts;
— unify sizes, weights, line-height, and spacing;
— update styles for buttons, cards, fields, badges, and headings;
— use common design tokens or CSS variables where possible;
— avoid duplicating styles separately for each page unnecessarily.
4. Unification of existing pages
Check and bring to the new style the main types of pages:
— catalog;
— model card / PDP;
— informational pages;
— header;
— footer;
— forms;
— modal windows;
— existing CTAs;
— loading / empty / error states, if they are already present in the project.
This is about the visual unification of existing components, not a complete individual redesign of each page.
5. Catalog
Check:
— card grid;
— images;
— name, reference, and price;
— filters and sorting;
— buttons and links;
— desktop/mobile display;
— loading and empty states;
— absence of visual shifts during loading.
6. PDP
Check:
— gallery;
— main information block;
— price and CTA;
— analytical sections;
— tables and metrics;
— About Watch;
— desktop/mobile layout;
— long names, references, and missing data.
It is necessary to maintain current functionality and existing API contracts.
7. Header and Footer
— unified style across all pages;
— responsive navigation;
— mobile menu;
— correct active/hover/focus states;
— absence of discrepancies between the homepage, catalog, and PDP.
8. Interface states
For dynamic blocks, check:
— loading;
— empty data;
— API error;
— insufficient data;
— missing image;
— missing price;
— long text;
— mobile display.
There is no need to develop new complex business logic. It is necessary to correctly visualize already existing states.
9. Quality and performance
— do not worsen SEO and current indexing;
— maintain correct metadata and semantic HTML;
— avoid critical layout shifts;
— optimize images and fonts;
— consider reduced motion for animations;
— check basic accessibility: focus states, contrast, keyboard navigation;
— do not include heavy libraries without justified necessity.
10. Staging and QA
— deploy changes on staging;
— check main types of pages;
— check desktop, tablet, and mobile;
— fix visual and responsive bugs;
— after acceptance, perform production deployment;
— ensure bug fixes for the implemented scope for at least 7 calendar days after deployment.
RESULT OF WORK
— Pull Request with frontend code;
— implemented new homepage;
— responsive desktop/tablet/mobile;
— unified fonts, cards, and basic UI components;
— visually agreed catalog, PDP, and informational pages;
— staging deployment;
— fixing identified visual errors;
— production deployment;
— brief description of modified components;
— 7-day bug-fix period after acceptance.
ACCEPTANCE CRITERIA
1. The homepage matches the provided design.
2. All sections work correctly on desktop, tablet, and mobile.
3. Header and footer are uniform across all pages.
4. Catalog and PDP visually correspond to the new system.
5. Current functionality of the site is not disrupted.
6. API contracts and backend logic are not changed without agreement.
7. No horizontal scrolling and critical layout shifts.
8. Fonts and images load correctly.
9. Loading, empty, and error states are displayed without breaking the layout.
10. Changes are checked on staging and deployed to production.
11. Visual errors identified during acceptance are fixed within the agreed scope.
WHAT IS NOT REQUIRED
— backend development;
— changes to business logic;
— creation of a new catalog or CMS;
— development of a new API;
— complete redesign of each informational page;
— new user features not present in the layouts;
— development of a complex design system from scratch;
— creation of a new project instead of improving the existing one;
— changes to the SEO structure without separate agreement.
REQUIREMENTS FOR THE PERFORMER
— confident in Next.js / React / TypeScript;
— experience working with existing production projects;
— quality responsive layout;
— experience implementing designs from Figma;
— component approach;
— confident working with CSS / CSS Modules / Tailwind or the existing project system;
— understanding of Core Web Vitals;
— Git / Pull Request workflow;
— ability to work through staging.
IN RESPONSE, IT IS MANDATORY TO INDICATE
1. Fixed price for the full mandatory scope.
2. Completion time in working days.
3. Estimate in hours.
4. When you are ready to start.
5. Links to 2–3 relevant projects on Next.js/React.
6. Experience working with catalogs, product cards, or analytical interfaces.
7. What will be needed for an accurate estimate before starting work.
8. Does the price include:
— staging;
— responsive QA;
— production deployment;
— bug fixes;
— 7-day bug-fix period.
Template responses without reviewing the requirements and without a specific estimate will not be considered.
Access to production is not provided at the first stage. Work begins after a limited code review and is deployed through staging.
