---
title: 'Про экономию на вёрстке от сторонних специалистов'
url: 'https://graker.ru/news/2025/10/09/call-freelancer-save-on-front-end'
language: ru
type: post
author: 'Роман Грачев'
published: '2025-10-09T13:45:00+03:00'
updated: '2025-10-09T13:55:44+03:00'
categories:
  - Разработка
---

# Про экономию на вёрстке от сторонних специалистов

![Про экономию на вёрстке от сторонних специалистов](https://graker.ru/sites/default/files/styles/max_1300x1300/public/uploads/2025-10/generated-image.png.webp?itok=NwdQdHfG)

Как-то раз, беседуя с заказчиком:

— Решили мы тут сэкономить и взять верстку фронт-энда со стороны. Вы сможете её натянуть на сайт?
— Сможем конечно, но обратите внимание, что без должного контроля за исполнением результат сторонней работы может оказаться не таким, как хотелось бы.
— А вы можете пообщаться с фронтом, рассказать ему требования, как делать, проверить его работу?
— Конечно, технадзор будет стоить вот столько, либо можно в почасовом режиме (t&m).
— Ну, нет. Я же сэкономить хочу и поэтому у него заказываю. Давайте я просто пришлю тогда, а вы натянете как есть.
— Хорошо, тогда мы просто базовый набор требований вам передадим, это бесплатно. И натянем как есть.

Вообще, мне идея сэкономить 2-3% от бюджета проекта на верстке, показалась странной. Но что поделать, может именно эта сумма в бюджет не вписывалась. Ну что ж, мы-то не против, надо так — давайте, пожалуйста, поработаем с вашей реализацией фронт-энда. Будем использовать предоставленный фронт «как есть». Просто мы знаем, чем это часто заканчивается.

Чтобы было понятно, еще раз: заказчик решил сэкономить. То есть нанять на вёрстку специалиста, который возьмет денег заведомо меньше, чем мы. *Значительно* меньше (иначе в чем экономия?) Давайте посмотрим, почему значительно меньше и с чем можно есть это «как есть».

Долго расписывать не буду, приведу один из знаковых моментов в предоставленных результатах.

В присланной верстке сторонний специалист переизобрел datepicker, то есть элемент выбора даты. Он решил, что вместо общепринятого текстового поля с иконкой справа, из которой вываливается календарик, нужно сделать три стилизованных селекта — день, месяц, год, а заодно заменить селектами обычные текстовые поля роста и веса. И, поскольку селекты стилизовать непросто, нужно сделать их на дивах, выпадающих из других дивов. Ну ок, так делают иногда. Правда, представленная реализация исключает возможность вручную вбить с клавиатуры нужное значение, а также ходить по списку стрелками вверх-вниз. К тому же, селекты были реализованы через скрытые радиобоксы, у которых почему-то отсутствовал атрибут value. Ну ладно, забыл, бывает.

При дальнейшем рассмотрении новаторского решения было найдено следующее. По ТЗ возможные значения для года — до 100 лет назад. Изобретатель вбил лет 15 возможных значений, вбил значения роста от 120 до 140 см, веса от 50 до 60. И дальше устал. Скрипт, который бы заполнил опции у всех полей автоматом, писать тоже почему-то не захотел. На вопрос, а где остальные 85 лет у года, сантиметры у роста и килограммы у веса, — то есть, значения полей, которые разработчики должны вставить «как есть», — демпингующий специалист ответил:

> «Сами вобьёте, мне делать больше нечего вам 200 строк вбивать вручную, я вам контентщиком не нанимался. Это просто пример как должен выглядеть селект, дальше сами разбирайтесь».

Вот ведь как, оказывается заполнять возможные поля в верстке селект-боксов должен контентщик.

Дальше оказалось, что сторонний разработчик не знает, что в месяцах бывает не только 31 день, но и 30, 28, и даже иногда 29. Поэтому в модном контроле ручной работы можно легко выставить 31-е февраля. Скрипт, ограничивающий число дней от выбора месяца, скрипт, проверяющий уж не високосный ли выбран год, и тем более скрипт, преобразующий 3 селекта в строковую дату — изобретатель решил не писать. Узнать почему, правда, не удалось, потому что после фееричного ответа про 200 строк заказчик из проекта его сразу удалил.

А в чем мораль? Мораль в том, что вот такую работу вы можете получить, когда отдаете часть проекта неизвестно кому, *чтобы сэкономить*. Но экспертизой принять работу при этом не обладаете. Вам сделают «просто пример как это должно работать» и делайте с этим примером что хотите. Потому что когда вы хотите заплатить за что-то меньше денег, очень вероятно, что вы и результата получите меньше тоже.

Что касается креативного подхода, уже не раз сталкивался с тем, что начинающие разработчики и дизайнеры переизобретают библиотеки, элементы интерфейса. Обычно это порождает ряд проблем, поскольку у автора изобретения пока нет достаточного опыта работы с существующими элементами. Поэтому новые велосипеды получаются лишенными ряда общепринятых функций, о которых изобретатель просто не подумал. Не нужно так делать, нужно тренировать насмотренность, интересоваться, что делают другие ребята, а ещё иногда спрашивать, реализуемо ли такое вообще. Тимлида, например.