Development of mobile applications

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.

There is an active production platform with a catalog and automatic updates of external offers and prices. Stack: — Node.js / TypeScript; — PostgreSQL; — existing price refresh service and cron; — separate ready Python module for validation and selection of offers; — staging and production. It is necessary to make targeted improvements to the existing price refresh pipeline without completely rewriting the backend. MANDATORY SCOPE 1. Integration of the Python module — The Python module remains a separate component; — returns a structured result: offers, selected offer, statuses, and risk flags; — Node.js validates the result and performs a write to the database; — provide for error handling and partial/failed runs; — the legacy pipeline is not turned off until QA is completed. 2. Launch refresh by list Add launch: — by one slug/id; — by the provided list of slug/id. Assume CLI or existing service API. A new user interface is not required. 3. Shadow Mode New results must be recorded separately and not affect production until QA. Shadow fields required: — price; — selected offer ID; — direct URL; — offer status; — risk/QA flags; — checkedAt; — engineVersion. 4. Expanding the existing offers table Add: — source; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — risk flags or storage in existing JSON; — unique constraint to protect against duplicates. It is not required to create a new parallel offer system if the existing table can be safely expanded. 5. UPSERT, STALE, and DB transaction Replace the current DELETE → CREATE scheme: — UPSERT existing and new offers; — offers missing in the full successful snapshot are translated to STALE; — in case of API error, partial result, or incomplete snapshot, active offers should not become STALE; — updating offers, selected offer metadata, and shadow fields for one model is performed within one DB transaction; — in case of an error, a full rollback is performed. 6. Canonical-safe refresh Price refresh should not change: — brand; — reference; — model; — collection; — name/title; — slug; — descriptions; — images; — SEO fields. Only offer, price, and shadow data are updated. 7. Preserving current cron logic Preserve: — existing cron; — rolling batches; — cooldown; — checking PRICE_REFRESH_MIN_DAYS before calling the external API; — legacy production pipeline until Shadow QA is completed. 8. Audit output One option is sufficient: — shadow columns in the existing admin table; or — CSV export. Minimum data: — model/reference; — production price; — shadow price; — delta; — production/shadow URL; — status; — risk flags; — checkedAt; — engineVersion. A new complex dashboard is not required. 9. Staging and QA — DB migrations; — staging deployment; — smoke test on 5 provided models; — then Shadow Mode on approximately 50 models; — fixing technical errors identified during these runs; — brief documentation of the Python → Node.js contract and rollback procedure. OPTIONALLY ASSESS SEPARATELY Simple technical promotion without a new UI: — promotion of one model by slug; — promotion of a list of slugs; — transferring confirmed shadow values to production; — technical check after rollout. RESULT — Pull Request; — DB migrations; — working integration Python → Node.js; — Shadow Mode; — UPSERT, STALE, and transactional update; — launch by slug/id; — staging deployment; — smoke-test results; — brief documentation; — at least 7 days of bug fixes for the implemented scope after acceptance. IN RESPONSE, INDICATE 1. Fixed price for the mandatory scope. 2. Separate cost for the promotion mechanism. 3. Timeline. 4. Hourly estimate. 5. When you are ready to start. 6. Experience with PostgreSQL transactions, migrations, and ingestion pipelines. 7. What questions need to be clarified before starting. 8. Whether staging, QA, migrations, and bug-fix period are included. Template responses without specific estimates will not be considered. Access to production is not provided at the first stage. Work begins with limited code review and staging.

Good day, 1) update jQuery** to the latest version (3.x) with jQuery Migrate included 2) Thoroughly test the functionality of the application 3) and fix any possible errors so that all scripts are compatible with each other by versions here it is necessary to completely rewrite https://filtry.in.ua/assets/libs/libs.js for the new version of jQuery since it has an old Bootstrap and many custom functions written

Description: It is necessary to create a JavaScript script for the Tampermonkey extension. The script will work in an internal CRM system.Logic of operation: The script must read the unique text ID of the current active dialogue on the page (there are a total of 5–10 different IDs). Depending on the ID, the script takes the corresponding text instruction (System Prompt) from the settings. The mapping of parameters by ID should be moved to a separate convenient settings window for the script. When a new message appears in the chat window, the script sends this text along with the prompt via the OpenAI API (model gpt-4o-mini). The received response is inserted into the text input field and initiates sending with a random delay of 20–45 seconds to simulate the natural operation of the operator.Work is purely with text. Budget — 6000 UAH. I am waiting for proposals from developers with experience in working with the OpenAI API and writing browser automation scripts.

A web service needs to be developed for automating the operations of coffee shops and small food service establishments. The product should have functionality similar to Poster POS, but with its own design, architecture, and source code. Copying the code or interface of Poster is not anticipated. The plan is to create a full-fledged commercial SaaS product that various coffee shops can use in the future on a subscription basis.In the first stage, an MVP needs to be developed Main functionality: registration and authorization of the establishment owner; creation of one or several establishments; management of employees and roles; catalog of products, categories, and modifiers; adding sizes, flavors, and additional options; cash interface for processing sales; opening and closing cash shifts; various payment methods; returns and order cancellations; inventory accounting and write-offs; basic stock accounting; sales history; reports on revenue, products, shifts, and employees; loyalty program for customers; adaptive operation on tablets, laptops, and smartphones; administrative panel for the service owner; tariff plans and restrictions according to the tariff.Future plans include mobile application; integration with payment terminals; receipt printing; integration with fiscal services; delivery and online ordering; table reservations; advanced analytics; API for third-party integrations; integration with accounting and CRM systems.Important requirements the system must be designed to operate multiple independent establishments; data of each client must be isolated; scalability of the product must be anticipated; secure handling of financial and personal data is required; the code must be structured and suitable for further development; technical documentation is needed; rights to the source code are transferred to the client after payment. At this moment, the design is absent, so a separate assessment of UI/UX design is needed or a ready-made solution for the MVP should be proposed.Please include in your proposal experience in creating SaaS, POS, CRM, ERP, or accounting systems; examples of similar work; proposed technology stack; team composition; estimated cost of the MVP; development timeline; what exactly is included in the proposed cost; cost of further support; whether you are ready to work in stages with payment for each completed stage. Preference will be given to performers or teams that have already developed cash, inventory, restaurant, or multi-user SaaS systems.