От идеи до готового проекта

Заказная разработка информационных систем под ключ - от архитектуры до эксплуатации и сопровождения. Быстро и надёжно: за результат отвечает один исполнитель, а фундаментом служит собственная открытая платформа, проверенная в реальных проектах с 2017 года.

Как это работает

От архитектуры до производственной версии и сопровождения. Один ответственный за результат.

1

Вникаю в задачу

Разбираюсь в ваших бизнес-процессах и цели. Не «пишу по ТЗ», а понимаю, что должно заработать и зачем.

2

Проектирую архитектуру

Под бизнес-цель, сроки и бюджет. Минимально достаточное решение вместо модного оверинжиниринга.

3

Довожу до production

На готовом фундаменте: авторизация, REST, workflow, файлы уже есть. Бюджет идёт на вашу логику, а не на инфраструктуру.

4

Сопровождаю

Эксплуатация, развитие, передача проекта. Система живёт годами, а не «сдал и забыл».

Заказная разработка

Проекты, разработанные на собственной кодовой базе для индивидуальных задач заказчика. Каждый проект - действующая система, которую можно открыть и проверить.

Зарядка EV

OCPP CSS

Розничный сервис для владельцев зарядных станций: подключение станции самостоятельно за ~15 минут, деньги водителей поступают напрямую на счёт владельца, чек 54-ФЗ - на его реквизиты. Бренд на платформе Apostol CSMS.

CSMSMulti-Tenant SaaSOCPPOCPIAFIRЮКассаPWA
ocpp-css.com ↗
Зарядка EV

PlugMe

Управление зарядными станциями EV в России. Сотни станций, тысячи водителей, интеграция с платёжными системами.

CSMSOCPPЮКассаMobile
plugme.ru ↗
Судоходство

Ship Safety ERP

Система управления безопасностью для судоходных компаний. СОЛАС и МКУБ. Внесена в реестр российского ПО.

ERPSOLASISMCompliance
ship-safety.ru ↗
AI

CopyFrog

AI-платформа для маркетинга и e-commerce: генерация рекламных текстов, изображений и видео для товаров и услуг, оркестрация нескольких AI-провайдеров, подписки и оплата картой.

AIOpenAIContentSaaS
copyfrog.ai ↗
ЖКХ

DEBT-Master

Автоматизация взыскания задолженности за ЖКУ для управляющих компаний и других организаций ЖКХ: досудебная работа, судебные приказы и иски, исполнительное производство, расчёт пеней по ЖК РФ, импорт данных и формирование судебных документов.

ЖКХВзысканиеФинансыОтчёты
debt-master.ru ↗
Финтех

Apostol ARB

Агрегатор арбитражных возможностей на криптофьючерсах: котировки Binance, Bybit, OKX, MEXC и Bitget в реальном времени, автоматический поиск арбитражных пар, сигналы трейдерам и управление через Telegram.

CryptoReal-timeWebSocketSaaS
arb.apostol-crm.com ↗
Геодезия

Campus CORS

Система передачи GNSS-коррекций в реальном времени по протоколу NTRIP: сеть базовых станций даёт сантиметровую точность позиционирования - точное земледелие, геодезия.

GNSSNTRIPIoTReal-time
cors.campusagro.com ↗
PetAI

Talking To AI

Telegram-бот для общения с искусственным интеллектом (ChatGPT). Реализован полностью на PL/pgSQL - от бизнес-логики и платежей до интеграции с OpenAI.

TelegramChatGPTPL/pgSQL
t.me/TalkingToAIBot ↗

И эти проекты работают годами

Системы держат нагрузку месяцами и годами без перерывов
Работают на скромном оборудовании - по памяти и CPU
Разворачиваются и обновляются одной консольной командой - за счёт современных инженерных практик

Быстро и надёжно

Разработка идёт быстро, а результат держится в эксплуатации годами. За счёт чего именно:

1

Готовый фундамент - A-POST-OL

Платформа A-POST-OL с открытым исходным кодом закрывает многие месяцы инфраструктуры из коробки: авторизация, REST API, workflow, файлы, очереди, audit log, локализация. Бюджет проекта идёт на вашу бизнес-логику, а не на изобретение колеса.

2

Один исполнитель - отдача команды

Собственные платформы как фундамент плюс AI-инструменты в разработке, ревью и документации дают объём, сопоставимый с командой, - при одной точке ответственности и прямом контакте с архитектором.

3

Production-надёжность

Режим 24/7, zero-downtime деплой, разделение dev/stage/prod, контроль миграций. Инженерная дисциплина из банковского домена, где цена ошибки - деньги.

Завод, а не гараж

Сначала - о надёжности. Вы получаете не одинокий станок в гараже, а полноценный завод с множеством независимых производственных линий: они не валятся разом, чинятся на ходу и обновляются без остановки. Зрелость, проверенная годами эксплуатации.

Приложение на A-POST-OL - один исполняемый файл, внутри которого главный процесс управляет независимыми «службами»: HTTP-обработчик, WebSocket-сервер, планировщик задач, генератор отчётов, OCPP-процессор. Упала одна - остальные работают, система сама поднимает замену. При этом своим компонентам не нужны ни HTTP-вызовы друг к другу, ни брокеры: модули с общими данными живут в одном процессе с общим epoll-циклом, а границу между процессами данные пересекают через PostgreSQL. По сути - микросервисная изоляция без микросервисной инфраструктуры.

Аналогия

Микросервисы - это парк отдельных грузовиков: один сломался, другие везут, но вы содержите целую логистическую компанию, чтобы их координировать. A-POST-OL - это один хорошо построенный завод с независимыми линиями: линия заклинила - остальные работают, а мастер тут же её перезапускает. А чтобы пережить пожар всего завода, строят второй завод - ровно как и все.

Надёжность - не в том, чтобы ничего не ломалось, а в том, чтобы поломка не валила всё.

Надёжность уровня nginx и PostgreSQL

Внутри система устроена так же, как самые проверенные программы в мире - веб-серверы и базы данных, которым доверяют банки: главный процесс управляет множеством рабочих. Упал один - остальные продолжают обслуживать, а система сама поднимает замену. Фоновые службы (рассылки, расписания, отчёты) работают отдельно: отвалился генератор отчётов - приём запросов не пострадал. Это та самая изоляция, которой хвалятся микросервисы, - но уже внутри одного приложения.

Обновления выкатываются плавно, без простоя - пользователи не замечают. А чтобы пережить отказ целого сервера или гигантскую нагрузку, добавляется обычный, скучный набор: второй сервер за балансировщиком и копия базы. Это стандартно и подключается тогда, когда реально понадобится, - архитектура этому не мешает.

Что это даёт вам

Сбой не роняет всё

Отдельная служба может упасть и сама перезапуститься - система продолжает работать.

Обновления без простоя

Новые версии поднимаются плавно; пользователи не видят остановки.

Растёт вместе с вами

Под отказ сервера и большую нагрузку добавляется стандартный набор - не раньше, чем понадобится.

Микросервисы дают такую устойчивость «из коробки», но ценой постоянной операционной сложности. Здесь надёжность есть сразу, а масштаб добавляется по мере необходимости - для большинства бизнес-систем это более трезвый выбор.

Платформа

Теперь - о скорости. У завода есть имя: A-POST-OL, собственная платформа для серверной разработки с открытым исходным кодом. Вот что она даёт вашему проекту с первого дня.

Любой проект начинается не с бизнес-логики, а с фундамента: вход и права доступа, хранение файлов, бизнес-процессы, уведомления, журналирование, отчёты, интеграции. На стандартном стеке это первые месяцы работы и заметная часть бюджета - потраченные не на то, ради чего проект задуман, а на инженерную «обвязку», без которой не обойтись. Именно здесь чаще всего копятся задержки, ошибки и дыры в безопасности.

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

Что вы получаете из коробки

Вход и права доступа

Регистрация, вход (в том числе через OAuth2 и соцсети), роли и тонкая настройка «кто что видит и может».

Документы и справочники

Единая модель для клиентов, счетов, заказов, договоров - с историей изменений и жизненным циклом.

Бизнес-процессы

Статусы и переходы (заявка → в работе → закрыто) настраиваются как данные. Процесс меняется без пересборки системы.

Файлы и хранилище

Вложения, сканы, фотографии. Облачное S3-совместимое хранение из коробки.

Уведомления и реальное время

Мгновенные обновления в интерфейсе, email/SMS/push, подтверждение почты и телефона.

Журнал и аудит

Кто, что и когда сделал - полный след для разбора спорных ситуаций и регуляторных требований.

Отчёты и выгрузки

Построение отчётов и документов по данным системы.

Интеграции

Готовый REST API на сотни методов, приём вебхуков и вызовы внешних сервисов - платёжных систем, AI, госсервисов - прямо из системы.

Десятки модулей · сотни готовых методов REST API · мультиязычность · адреса РФ (КЛАДР) · настройки в рантайме без программиста

Готовые подсистемы

Сверх базовых блоков - целые бизнес-механизмы, уже собранные и обкатанные на нескольких проектах. Их не нужно проектировать заново.

Платежи и эквайринг

Приём платежей через Stripe и ЮKassa под разные рынки - единым способом. Привязка карт и автосписание, резервирование суммы (pre-auth hold), возвраты, проверка карты, оплата счетов.

Учёт по счетам (двойная запись)

Лицевые счета: кошельки, обязательства, задолженности. Обороты по дебету и кредиту, входящий и исходящий остаток, оборотная ведомость с агрегацией по дням, неделям и месяцам. Бухгалтерская строгость на уровне базы.

Подписки и биллинг

Продукты, тарифы и периоды; автопродление по расписанию, пробный период, смена тарифа с pro-rata пересчётом остатка, отмена. Полный жизненный цикл подписки и привязка к лимитам (например, числу устройств).

Одни и те же блоки лежат в основе систем для зарядок EV, AI-генерации, геодезии и взыскания ЖКХ-задолженности.

Под капотом

Три инженерных решения, на которых держатся и скорость, и надёжность. Здесь - суть; подробный разбор для технических специалистов - ниже, в разделе «Одно ключевое отличие».

Главная цель

Ноль слоёв между запросом и базой

Большинство фреймворков добавляют между HTTP-запросом и PostgreSQL несколько слоёв - ORM, отдельный пул соединений, свой IO-цикл. A-POST-OL убирает всё лишнее: HTTP и PostgreSQL работают в одном epoll-цикле. Результат - не только скорость, но и архитектурная простота: меньше движущихся частей, меньше мест для ошибки, меньше дополнительных сервисов.

Главная ценность

Консистентность данных

Бизнес-логика живёт в самой PostgreSQL: транзакции, проверка остатков, расчёт цен, защита от двойных списаний - атомарны на уровне БД, без промежуточных слоёв. Это критично для e-commerce и финансовых операций. Близкий подход у Supabase, но там прикладную логику принято ограничивать RLS и edge-функциями - здесь же на PL/pgSQL реализована вся бизнес-логика.

И вдобавок - производительность

Единый event loop, асинхронный PostgreSQL без потоков и блокирующих вызовов - следствие той же архитектуры: на чистом HTTP - 90% скорости nginx, а в производственном сценарии, с запросом к базе на каждый HTTP-запрос, - 112 тысяч RPS при задержке меньше миллисекунды. Открытый бенчмарк:

507K RPS - 90% скорости Nginx → бенчмарк

Платформа - конструктор из трёх слоёв

Один и тот же стек у множества production-проектов. Меняется только верхний слой - бизнес-логика.

Уровень 3

Configuration - ваш проект

Apostol CSMSЗарядка EVCampus CORSГеодезияTalking To AIAIDEBT-MasterЖКХCopyFrogAIPlugMeЗарядка EVShip Safety ERPСудоходство

Уникальная бизнес-логика. Всё, что отличает CSMS от ERP, живёт в этом слое.

Расширяет платформу. Никогда не модифицирует её.
Уровень 2

Platform - общая для всех

100% переиспользованияdb-platform wiki ↗

auth · OAuth 2.0 · workflow · entity · файлы (S3) · pub/sub · audit log · notifications · локализация · отчёты · registry · KLADR · …

Десятки модулей · сотни REST-методов · никто не пишет ни строки в этом слое

libpq async · один epoll event loop
Уровень 1

Transport - C++ server

libapostol wiki ↗

HTTP / WebSocket · TLS · epoll · libapostol

Как nginx или сама PostgreSQL - не часть вашего проекта.

Десятки модулей платформы переиспользуются во множестве проектов без единой строки своего кода. Модуль приёма платежей Stripe, написанный для CopyFrog, без переделки переиспользуется в других проектах - например, в Apostol CSMS. По тому же принципу собирается интернет-магазин, ERP или IoT-платформа - уникальная логика живёт только в верхнем слое.

Workflow engine - это данные

Состояния, переходы и события бизнес-процессов хранятся в таблицах БД, а не в коде. Меняете workflow без пересборки сервиса.

- на практике это решение снова и снова оказывается самым полезным в архитектуре платформы.

Время - это деньги

Платформа - это не только технология, но и многие месяцы работы команды разработчиков, которые в обычном проекте уходят на инфраструктуру: auth, workflow, REST, файлы, очереди, audit log, локализацию. Здесь это уже отлажено в production у множества систем. Бюджет вашего проекта остаётся на бизнес-логику, а не на повторное изобретение колеса.

- по моей оценке, повторить сопоставимую по зрелости систему с нуля без новых возможностей на стандартном стеке заняло бы годы разработки и миллионы бюджетных средств.

Одно ключевое отличие

Конструктор из трёх слоёв - это ЧТО. Здесь - ПОЧЕМУ именно так, а не стандартным стеком. Раздел для технического читателя: если техника не про вас, достаточно врезки ниже - остальное можно смело пролистать.

Коротко

В обычной архитектуре приложение и база данных - два отдельных мира: данные ходят между ними туда-обратно, и каждый переход стоит времени и создаёт место для ошибки - вплоть до двойного списания денег. В A-POST-OL приложение и база работают как одно целое: любая операция с деньгами - одно неделимое действие. Отсюда скорость без дорогого «железа» и невозможность целого класса дорогих ошибок - по построению, а не благодаря аккуратности программиста.

Возьмём конкретную задачу: «Проверить баланс и списать деньги» Она есть в каждом транзакционном проекте - e-commerce, биллинг, ERP, ЖКХ.

На Python / Node.js / Go:

HTTP requestApp serverPython · Node.js · GoPostgreSQLSELECT balance FROM dbround trip 1temporal gapif balance >= price: ← in-memory logica concurrent request reads the same balance hereUPDATE balance - priceround trip 2INSERT INTO orders …round trip 3HTTP response

Проблема: временной зазор

Между SELECT и UPDATE - временной зазор. Параллельный запрос успевает прочитать тот же баланс до того как первый его обновил. Итог: двойное списание, oversell, гонка при бронировании. Решение - явная дополнительная механика: SELECT FOR UPDATE, optimistic locking, Redis-блокировка. Это хорошо известные инструменты - но это дополнительный код, дополнительные зависимости и дополнительное место для ошибки.

На A-POST-OL:

HTTP requestC++ workerepollPostgreSQLlibpq async: SELECT debit(user_id, amount)PL/pgSQL · one transactionSELECT balanceIF balance < amount → RAISEUPDATE balanceINSERT INTO ordersatomic · no temporal gapresult · one round tripHTTP response

Нет зазора. Нет трёх round trip'ов. Нет дополнительных блокировок. PostgreSQL сериализует параллельные вызовы самостоятельно - это свойство ACID, а не дополнительный код.

Когда нужна передача данных между процессами

например, поток событий из внешнего источника (IoT, биржа, телеметрия)

На Python:

Process Aparse → dict → Pydantic → JSONRedis · XADD / XREADnetwork callJSON → PydanticProcess B5–7 serializations per event

Типичный сервис обработки событий на Python делает 5–7 сериализаций на каждое событие. При 1 000 событий/сек - это тысячи операций только на то, чтобы передать число из одного своего процесса в другой. CPU уходит на транспорт, не на бизнес-логику.

На A-POST-OL:

External source · WebSocketone process · one epoll loop · shared heapModule A · parsecache[key] = valuein memory · 0 serializationsModule B · reads the same cacheprocess boundarylibpq NOTIFY → PostgreSQL → WS pushthe only cross-process hop - via PostgreSQL

Компоненты, которые в Python были бы отдельными процессами, здесь - модули одного процесса с общим epoll-циклом: кэш читается напрямую из памяти самого процесса. Границу между процессами данные пересекают один раз - через PostgreSQL LISTEN/NOTIFY. Нет Redis. Нет JSON между своими модулями. 0 сериализаций.

Почему это возможно: база данных - не «внешний сервис», а часть приложения

Python / Node.js / Go

В Python/Node.js/Go - PostgreSQL это внешний сервис. Каждый вызов: взять соединение из пула → отправить по TCP → ждать → получить → распарсить. Даже с async-драйвером - это отдельный IO-цикл с накладными расходами.

A-POST-OL

В A-POST-OL - сокет PostgreSQL зарегистрирован в том же epoll-цикле, что и HTTP-сокеты. Когда база ответила - epoll срабатывает так же, как когда клиент прислал следующий байт. Нет отдельного потока в ожидании. Нет контекстного переключения. Нет очереди между «получил HTTP-запрос» и «ответил из базы». База - «на расстоянии вытянутой руки».

Python / Node.js / GoA-POST-OL
Обращение к PostgreSQLTCP + парсинг + пул потоковepoll event в том же цикле
Передача данных между процессамиRedis / Kafka / gRPClibpq NOTIFY / память
Гонка при check + updateнужны явные блокировкиустранена архитектурно
Redis как кэшнужен - PG «далеко»не нужен - PG и так «рядом»
Брокер сообщенийнужен для async workflowPostgreSQL LISTEN/NOTIFY

Именно отсюда 507K RPS на чистом HTTP - и 112K RPS, когда каждый запрос ходит в базу. Именно поэтому брокер сообщений не нужен для внутренней коммуникации. Именно поэтому бизнес-логика может жить внутри транзакции без накладных расходов - потому что вызов к базе стоит столько же, сколько обработка следующего HTTP-пакета.

В переводе с инженерного: там, где обычно собирают кластер сервисов, здесь хватает одного недорогого сервера; в схеме меньше компонентов, которые могут отказать и которые нужно оплачивать и обслуживать; а ошибки класса «деньги списались дважды» исключены самой конструкцией.

A-POST-OL создавался как ответ на конкретный вопрос: как убрать все слои между HTTP-запросом и транзакцией PostgreSQL. OCPP (протокол зарядных станций) - наглядный пример, где это требование стоит остро: тысячи станций, постоянные WebSocket-соединения, каждое сообщение должно попасть в базу атомарно и немедленно. Та же архитектура работает в ERP, финтехе и IoT - потому что требование одно и то же: данные консистентны, а не «eventually consistent». Цена архитектурного решения - бизнес-логика на PL/pgSQL вместо привычных Python или Go. Разработчиков, которые пишут прикладную логику на PL/pgSQL, на рынке труда немного. Это реальное ограничение, о котором лучше знать заранее.

Платформа - это ядро, к которому подключаются микросервисы на уместном языке. В DEBT-Master вокруг ядра работают пять Python-сервисов (парсинг Excel/PDF/RTF, OCR, генерация документов); в CopyFrog - оркестрация AI-провайдеров. Правильный инструмент под задачу, а не «всё одним стеком любой ценой».

Почему свой путь, а не проторённая дорога

Три вопроса, которые обычно остаются у опытного скептика после всего прочитанного, - и ответы по существу.

Вопрос скептика

Если эта архитектура настолько выигрышна - почему так не строят все?

Потому что массовый стек решает другую задачу. Он оптимизирован под главное ограничение больших организаций: десятки взаимозаменяемых разработчиков, которых нужно быстро нанимать и безболезненно заменять. Отсюда его слои: ORM - чтобы не требовать глубокого SQL, микросервисы - чтобы делить работу между командами, брокеры сообщений - чтобы команды не согласовывали каждый релиз. Для той задачи это рациональные решения.

Здесь ограничение другое: компактная команда, транзакционная корректность и дешёвая эксплуатация на годы вперёд. Другое ограничение - другой оптимум. Свой путь - не бунт против индустрии, а честная оптимизация под свою задачу.

Вопрос скептика

Бизнес-логика в базе данных? Это уже проходили в 2000-х - и отказались

Отказались заслуженно - но не от идеи, а от инструментария эпохи: код хранимых процедур жил вне систем контроля версий, без тестов и ревью, привязывал к дорогой проприетарной СУБД, а каждое изменение стояло в очереди к администратору базы.

Здесь всё это устранено конструктивно иначе: PostgreSQL - открытая и бесплатная; весь PL/pgSQL код не хранится в БД - это обычные файлы в git с ревью, автоматическим развертыванием (загрузкой кода в БД), контролируемыми миграциями и сотнями автотестов; у каждой сущности - один и тот же дисциплинированный набор файлов; REST-слой строится автоматически. Показательно, что индустрия и сама возвращается к логике рядом с данными: Supabase, PostgREST, Hasura - шаги по той же дороге.

Общая картина видна на реальных проектах: у DEBT-Master, CopyFrog, campus/cors и Apostol CSMS - у каждого свой git-репозиторий и свой Docker Compose, но принцип один: весь PL/pgSQL-код лежит обычными файлами в этом репозитории, версионируется и ревьюится как любой другой код, а Docker Compose лишь разворачивает его в контейнере с PostgreSQL при старте или обновлении - то есть база данных для PL/pgSQL-кода то же самое, чем Docker-образ является для кода на Python, Node.js или Go: упаковка и среда исполнения, а не хранилище исходников. Открытый минимальный пример этого - шаблон Apostol CRM:

→ Apostol CRM - git clone → docker-build.sh → docker-up.sh

В Apostol CSMS этот же принцип доведён до полноценного конвейера: пять исходных репозиториев (backend, ocpp, db, frontend, auth) публикуются по единому git-тегу; каждый бренд-деплой фиксирует точные версии в одном lock-файле и переезжает на новый релиз одной командой; а накат схемы базы - обязательный блокирующий шаг конвейера: если миграция не прошла, выкладка новой версии останавливается сама, без ручного администратора базы на другом конце.

Вопрос скептика

Платформа одного автора - откуда взяться зрелости?

Оттуда же, откуда она у Rails, выросшего из Basecamp, и у Django, выросшего из газетной редакции: платформа не проектировалась «на бумаге» - она выделена из работающих заказных систем. Каждый модуль появился потому, что понадобился реальному проекту, и обкатан в нескольких непохожих доменах.

Поэтому в ней нет умозрительных возможностей «на вырост» - только то, что уже окупило себя в эксплуатации с 2017 года. А открытый код позволяет проверить это чтением, а не доверием.

Архитектура платформы универсальна

Платформа подходит для любого проекта, где нужна надёжная серверная часть с готовой инфраструктурой. Apostol CSMS - лишь один из примеров. Ваш проект может стать следующим.

E-commerce

Multi-tenant, multi-payment, расчёт налогов по странам, очереди для интеграций с маркетплейсами (Amazon, Wildberries), журнал действий, защита от двойных списаний.

FinTech

Real-time данные через WebSocket, OAuth 2.0, биллинг и сверка платежей, журнал действий, интеграции с биржами и платёжными системами.

ERP / документооборот

Workflow-движок (состояния, переходы, события), документооборот, отчёты, файловое хранилище с S3-совместимостью, мультиязычность.

IoT и зарядная инфраструктура

Высокая нагрузка через единый event loop, persistent WebSocket-соединения, OCPP/OCPI/NTRIP, обработка телеметрии в реальном времени.

AI-сервисы

Асинхронные задачи, очереди для LLM API, file storage для входных данных и результатов, биллинг по использованию, multi-tenant.

SaaS общего назначения

Authentication из коробки (OAuth 2.0, JWT, signup), tenant-изоляция, white-label, локализация, журнал действий - всё, что нужно стартующему SaaS.

Идеально подходит

  • Транзакционные системы: финтех, биллинг, e-commerce, ERP, платежи, ЖКХ-автоматизация
  • Real-time и долгоживущие соединения: IoT, зарядки (OCPP), телеметрия, стриминг, WebSocket
  • Multi-tenant SaaS / white-label, режим 24/7, дешёвая эксплуатация
  • Интеграционные хабы - оркестрация прямо из базы данных

Лучше искать иное решение

  • Frontend/UX-first продукты с тонким бэкендом - платформа избыточна
  • Продукты, где ядро ценности - ML/AI-пайплайны (платформа подойдёт только вокруг них)
  • Когда нужно быстро нанять большую команду и важна ликвидность «модного» стека
  • Глобальный горизонтальный масштаб с первого дня

Apostol CSMS (зарядная инфраструктура) - пример зрелого SaaS-продукта на платформе. Архитектура та же, домен другой.

Подробнее об архитектуре платформы →

Ваш проект - ваш код

Независимость от исполнителя заложена в архитектуре.

Открытый фундамент

Платформы A-POST-OL и db-platform - open-source (MIT), в эксплуатации с 2017 года. Никакого закрытого «чёрного ящика».

Исходники у вас

Код проекта остаётся у заказчика. Бизнес-логика написана на PL/pgSQL - это SQL-диалект PostgreSQL, понятный любому разработчику, умеющему работать с базами данных.

Передаваемость

Проект можно сопровождать и развивать через любого PostgreSQL-разработчика - привязки к одному человеку нет.

Условия и стоимость

Два формата работы

Под ключ

Беру проект целиком - от архитектуры до вывода в production и сопровождения. Одна точка ответственности.

2 500 ₽/час

20 000 ₽/день · 100 000 ₽/неделя · 400 000 ₽/месяц

В команде заказчика

Встраиваюсь в вашу команду на проектной основе или усиливаю бэкенд. Работаю внутри ваших процессов.

1 500 ₽/час

12 000 ₽/день · 60 000 ₽/неделя · 240 000 ₽/месяц

Минимальная загрузка - 1 неделя в месяц; дальше вы сами решаете объём.

Стоимость проекта

Для ориентира по итоговой стоимости проекта:

Компактный MVP или интеграция на готовом фундаменте1-1,5 месяца400 000-600 000 ₽
Production-система с несколькими ролями пользователей и платежами3-5 месяцев1 200 000-2 000 000 ₽
Multi-tenant SaaS уровня Apostol CSMSот 6 месяцевот 2 400 000 ₽

Точная сумма и срок - после короткого созвона и понимания объёма задачи. Загрузку можно держать неполной: меньше бюджет в моменте - меньше часов в неделю, а не отказ от исполнителя.

Об исполнителе

Ален Преподобный - ИП с 2021 года. 25+ лет в ИТ, 10+ из них - техническим директором; вырос в банковском ИТ, где цена ошибки измеряется деньгами. Беру проект, вникаю в бизнес-процессы заказчика и довожу его от идеи до production, а затем сопровождаю. A-POST-OL и db-platform - мои собственные инструменты, выросшие из реальных проектов: зарядная инфраструктура, морская безопасность, финтех, геодезия.

Заказная разработка

  • ИП Преподобный Ален Алексеевич - для клиентов из России
  • Для клиентов из Европы и других стран - работаем через партнёров в ЕС
apostoldevel@gmail.com@apostoldevelОГРНИП: 321508100604655

Связаться

Расскажите о задаче - отвечу в течение дня

Что дальше

  1. 1Отвечаю в течение дня - лично, не бот и не менеджер.
  2. 2Созваниваемся на 30 минут - бесплатно, без обязательств, чтобы понять объём задачи.
  3. 3Присылаю письменный ориентир по срокам и бюджету - дальше решаете вы.