Разработка на заказ
Не каждую задачу решает сайт. Когда нужен инструмент, приложение, интеграция или процесс, который больше не должен делаться руками, мы создаём именно это.
Маленькая опытная команда, честная в вопросах объёма работ. Если вашу задачу уже решает готовый продукт, мы так и скажем, вместо того чтобы выставлять счёт за его повторное изобретение.
Реестр
Какие задачи мы берём в работу
Заказное ПО удобно описывать через задачу, которую оно снимает. Вот самые частые ситуации и то, что мы обычно в итоге строим.
| Задача | Что мы строим |
|---|---|
| Одна и та же ручная задача каждый день, которую делает слишком опытный для неё человек | Внутренний инструмент, где шаги закреплены один раз: форма, очередь, понятный журнал действий и права доступа, которые соответствуют реальной работе команды. |
| Две системы, которые не хотят общаться друг с другом | Интеграция, которая берёт на себя сопоставление данных между ними, безопасно повторяет попытки, когда одна сторона недоступна, и сообщает, когда нужен человек. |
| Бизнес держится на таблице, которую никто не решается тронуть | Небольшое веб-приложение с настоящей моделью данных внутри, где два человека могут работать одновременно, а цифры прошлого квартала нельзя случайно перезаписать. |
| Отчёт, который кто-то каждую неделю собирает вручную | Задача по расписанию, которая собирает данные, проверяет их и доставляет отчёт нужным людям, сохраняя запись о каждом запуске. |
| Работа, которая происходит не за столом: на телефоне, в фургоне, в цехе | Мобильное приложение на той же основе, что и остальная система: общая модель данных, общий стандарт ревью и общие автоматические проверки, поэтому телефон и десктоп никогда не расходятся в фактах. |
| Клиентский процесс, прикрученный к маркетинговому сайту, пока тот не сломался | Полноценное приложение по своему адресу, использующее дизайн-систему сайта, чтобы всё выглядело одной компанией. |
| Задача, которую никто не может оценить, потому что её никто не описал | Короткий этап обследования: минимальная рабочая версия описана письменно, а то, что мы не будем строить, указано так же прямо. |
Подход
Как мы решаем, что строить
- Сначала минимально рабочее решение. Узкий инструмент в проде за две недели учит больше, чем полная спецификация за квартал, а расширять его можно, когда станет ясно, что действительно важно.
- Намеренно скучные технологии. Мы выбираем проверенное решение, а не интересное. Заказное ПО оценивают в день, когда его нужно изменить, а не в день запуска.
- Модель данных решается в первую очередь. Интерфейс перерисовать дёшево, а данные перестроить дорого, поэтому структура данных фиксируется раньше экранов.
- Сначала купить, потом строить. Если готовый продукт закрывает вашу задачу, мы честно порекомендуем использовать его. Мы лучше построим небольшой кусок, который его подключит, чем возьмём деньги за повторное изобретение.
- Проектируем для второго разработчика. Читаемый код, задокументированная настройка, тесты, объясняющие замысел. Мера качества работы в том, может ли кто-то другой безопасно её изменить.
Стек
Технологии, которые мы реально используем
Мы прямо называем технологии, потому что это часть честного разговора об объёме работ. Технический покупатель должен понять с одного экрана, подходящая ли мы студия, а нетехнический должен суметь передать этот раздел своему разработчику и получить точный ответ.
TypeScript, от начала до конца
Astro, обычные HTML и CSS, React там, где это нужно приложению, а также мобильные приложения
Node и Cloudflare Workers
Совместимые с Postgres базы данных, версионируемые SQL-миграции
Cloudflare Pages, Workers, объектное хранилище, задачи по расписанию
Playwright, Vitest, статическая типизация, автоматические проверки доступности
- Один язык для всей системы. TypeScript и для интерфейса, и для API, и для задач по расписанию, и для тестов, с проверкой типов при каждом изменении. Один язык означает один набор инструментов и один стандарт код-ревью, а также отсутствие прослойки перевода между браузером и сервисом за ним.
- Способ рендеринга выбирается под задачу. Контент компилируется в статический HTML. Интерфейс, которому действительно нужно клиентское состояние, получает компонентный фреймворк, ограниченный именно той частью экрана, где он нужен, а не оборачивающий контент, который никогда не меняется.
- Мобильные приложения на общей дисциплине. Там, где работе место в руке, а не во вкладке браузера, мы строим приложение по тому же стандарту, что и всё остальное: тот же TypeScript-ориентированный набор инструментов, тот же стандарт ревью, те же автоматические проверки и та же модель данных, что и у сервиса за ним, а не отдельный источник истины. Какой стек использовать для конкретного приложения, мы решаем вместе с вами на этапе согласования объёма работ, а не применяем как единое предпочтение студии для каждого проекта.
- Реляционная база данных, а не свалка документов. Совместимая с Postgres база данных с типизированным слоем запросов, а изменения схемы проходят ревью, применяются по порядку и обратимы. Никто не правит рабочую схему вручную.
- Serverless по умолчанию, потому что нет сервера, о котором можно забыть. Код работает на edge-платформе Cloudflare, с объектным хранилищем для файлов и задачами по расписанию для всего, что должно происходить по таймеру. Нет вашей машины, которую нужно патчить среди ночи, и нет мощностей, которые приходится угадывать.
- Интеграции через задокументированные интерфейсы. К другим системам мы обращаемся через их API и вебхуки, с повторами при сбое, идемпотентностью и записью каждого вызова. Если у поставщика нет API, намеренным резервным вариантом становится файл или фид по расписанию, а не скрейпинг экрана, который сломается в следующем квартале.
- Окружения и секреты как конфигурация, а не как устные предания. Инфраструктура описана в репозитории, учётные данные хранятся в отдельном хранилище секретов и попадают в работающий сервис как переменные окружения, а новая машина запускает проект в тот же день.
- Ваш стек, если он у вас уже есть. Если ваша команда поддерживает что-то разумное, правильный ответ обычно в том, чтобы работать внутри него, а не вводить второй способ делать всё то же самое. А если проблема действительно в том, что у вас есть, вы услышите и это.
Стандарты
Та же инженерная база, что и у сайтов
База не меняется между двумя направлениями, потому что внутренним инструментом годами пользуются люди, у которых нет выбора другого. Обычный код в репозитории с полной историей, автоматические проверки, останавливающие красный деплой, релизы одной командой с откатом в один шаг, доступные интерфейсы (сотрудники заслуживают того же стандарта, что и клиенты), секреты вне кода и никакой закрытой платформы под всем этим. Подробно это описано в разделе про корпоративные сайты, а не повторяется здесь.
В программном обеспечении есть два момента, которые весят больше, чем на сайте, и их стоит назвать отдельно.
Данные переживают код
Интерфейсы со временем заменяют, а записи остаются. Поэтому изменения схемы оформлены как миграции в репозитории, применяются по порядку и обратимы, за резервное копирование отвечает платформа, а не скрипт, который кто-то написал один раз, а ваши данные можно выгрузить в формате, который можно загрузить куда угодно ещё.
Работающая система должна быть наблюдаемой
Всё, что происходит без наблюдения, оставляет след: что запустилось, когда, чего коснулось и на чём споткнулось. Задача по расписанию, которая тихо перестала работать, сообщает нам об этом сама, а не обнаруживается через месяц человеком, который искал пропавший отчёт.
Границы
Где мы останавливаемся
Ясность в вопросах границ работы формирует доверие к нам. Мы маленькая опытная команда, поэтому берёмся за то, что можем сделать хорошо, и отказываемся от того, что не можем.
Мы не перепродаём лицензированные платформы, не выделяем людей на проект, который не строим сами, и не называем цену для задачи, которая ещё не описана. Если часть работы относится к области другого специалиста, мы скажем об этом прямо, а не дадим вам узнать это за свой счёт.
Технические границы так же конкретны:
- Использование готовой модели да, дата-сайенс нет. Мы обращаемся к готовой модели или существующему сервису из вашего приложения и строим вокруг него интерфейс и всю обвязку. Обучение моделей, статистический анализ и конвейеры данных промышленного масштаба не входят в то, чем мы занимаемся.
- Управляемые платформы да, свои серверы нет. Мы разворачиваем проекты на управляемых edge- и serverless-платформах. Если работа должна выполняться в вашем дата-центре, на машинах, которые администрируете вы, или на операционной системе, которую кому-то приходится патчить, мы не та студия, и вы услышите это уже на первом звонке.
- Сертифицированные режимы требуют отдельного специалиста. Мы применяем настоящую инженерию безопасности по умолчанию, но формальный аудит на соответствие конкретному регламенту не входит в то, что мы продаём. Если вашему проекту это нужно, мы скажем об этом до подписания, а не после.
- Прошивка и перепродажа. Встроенная прошивка не наша дисциплина, как и всё, чья ценность сводится к перепроданной лицензии, а не проделанной нами работе.
Эксплуатация
Кто поддерживает систему после запуска
Заказное ПО не заканчивается в день запуска. Им начинают пользоваться, а затем в нём нужно что-то менять. Кто эксплуатирует систему и кто её меняет, стоит прописать в объёме работ с самого начала, а не выяснять в неловком письме через полгода.
Мы размещаем систему и поддерживаем её работу
Это вариант по умолчанию: мы размещаем и обслуживаем систему за ежемесячную плату, а изменения после запуска проходят тот же цикл, что и сама разработка: ветка, предпросмотр, полный набор проверок и деплой, откатываемый одним шагом. Систему написали те же люди, которые следят за ней в продакшене, а это обычно и есть разница между тихим исправлением и долгой перепиской о том, чья это проблема.
У того, что мы маленькая опытная команда, есть цена, и мы предпочитаем сразу её назвать: мы не держим круглосуточное дежурство и не продаём гарантированный ответ, измеряемый в минутах. Если вашему проекту это действительно нужно, скажите об этом заранее, и мы честно ответим, сможем ли мы это обеспечить.
Или ваша команда берёт систему на себя
Если это предусмотрено договором, систему можно передать на ваш собственный хостинг и вашим собственным разработчикам: обычный код, тесты, задокументированная настройка и деплой одной командой. Именно для этого и нужен принцип проектирования для второго разработчика, о котором говорилось выше. Это вариант, который мы фиксируем письменно по вашему желанию, а не порядок по умолчанию.
Платформа помогает и здесь. У статического сайта и serverless-сервиса нет сервера, который нужно патчить, и нет операционной системы, которую нужно обновлять, поэтому остаются только обновления зависимостей и платформы: плановое, проверяемое изменение, а не аварийная ситуация.
Для начала не нужна спецификация. Напишите через форму на сайте или на sales@wwi.dev и опишите задачу простыми словами.