Розробка системи управління проектами (Project Management)

Чому варто розробити власну PM-систему?

Ми розробляємо системи управління проектами під ключ, коли готові SaaS-продукти не підходять: галузева специфіка, жорсткі вимоги до даних, інтеграція з внутрішніми системами. Замість Jira або Asana ви отримуєте інструмент, заточений під ваш бізнес-процес. Нижче — архітектура, кодова база та терміни. Замовте оцінку проекту, щоб зрозуміти деталі. За 10+ років ми реалізували понад 50 проектів — від модульних монолітів до розподілених систем.

Власна PM-система вирішує три головні проблеми: нестандартні воркфлоу, які не можна переналаштувати в готовому продукті; висока вартість ліцензій при масштабуванні; необхідність глибокої інтеграції з корпоративним стеком. За нашими даними, економія на ліцензіях при 500+ користувачах досягає 60%, а скорочення часу на воркфлоу — 40%. Кастомна PM-система окупається в середньому за 12-18 місяців. Зв'яжіться з нами, щоб отримати консультацію.

Порівняння: кастомна PM-система vs Jira

Архітектура та модель даних

Центральні сутності: Project → Milestone → Task → Subtask. Поперечні: User, Team, Comment, Attachment, TimeLog, Activity. Зв'язки: задача може належати кільком проектам через епіки, користувач — різні ролі, залежності між задачами утворюють граф.

Модульний моноліт — правильний вибір для проектів до 50 000 активних користувачів. Мікросервіси виправдані, коли окремі компоненти масштабуються незалежно. 90% систем PM будуються як модульний моноліт і залишаються ним назавжди.

Event-driven всередині моноліту. Переходи станів, призначення, зміни дедлайнів — все це події, що тригерять побічні ефекти (сповіщення, дашборди, логи). Використовуємо внутрішній event bus: в Laravel Event::dispatch(), в Node.js — EventEmitter.

CREATE TABLE tasks (
  id          BIGSERIAL PRIMARY KEY,
  project_id  BIGINT NOT NULL REFERENCES projects(id),
  parent_id   BIGINT REFERENCES tasks(id),
  path        LTREE NOT NULL,           -- PostgreSQL ltree: '1.5.23'
  title       VARCHAR(500) NOT NULL,
  status      task_status NOT NULL DEFAULT 'todo',
  priority    SMALLINT NOT NULL DEFAULT 2,
  assignee_id BIGINT REFERENCES users(id),
  due_date    DATE,
  estimate    INTEGER,                  -- в хвилинах
  created_at  TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX tasks_path_gist ON tasks USING GIST (path);
CREATE INDEX tasks_project_status ON tasks (project_id, status);

Цей підхід з ltree описаний в документації PostgreSQL.

Залежності між задачами:

CREATE TABLE task_dependencies (
  task_id       BIGINT REFERENCES tasks(id),
  depends_on_id BIGINT REFERENCES tasks(id),
  type          dep_type NOT NULL,
  PRIMARY KEY (task_id, depends_on_id)
);

Перед збереженням залежності перевіряємо циклічність — обхід графа в глибину або рекурсивний CTE.

Як реалізувати воркфлоу та реалтайм?

Воркфлоу — головна причина розробки власної системи. Підхід: налаштовувані воркфлоу на рівні типу задачі. Кожен тип (Task, Bug, Epic) має власну state machine з різними переходами та guards.

// Laravel + winzou/state-machine
'bug' => [
    'graph' => 'bug_workflow',
    'property_path' => 'status',
    'states' => ['new', 'triaged', 'in_progress', 'in_review', 'resolved', 'closed', 'reopened'],
    'transitions' => [
        'triage'   => ['from' => ['new'],         'to' => 'triaged'],
        'start'    => ['from' => ['triaged'],      'to' => 'in_progress'],
        'review'   => ['from' => ['in_progress'],  'to' => 'in_review'],
        'resolve'  => ['from' => ['in_review'],    'to' => 'resolved'],
        'close'    => ['from' => ['resolved'],     'to' => 'closed'],
        'reopen'   => ['from' => ['resolved', 'closed'], 'to' => 'reopened'],
    ],
    'callbacks' => [
        'after' => [
            'notify_assignee' => ['on' => ['start', 'review'], 'do' => 'NotifyAssigneeCallback'],
        ],
    ],
],

Конфігурація воркфлоу зберігається в базі, редагується через візуальний конструктор.

Покрокове налаштування state machine

1. Визначте стани та переходи для кожного типу задачі.
2. Створіть guards для перевірки прав та умов.
3. Зареєструйте callbacks для сповіщень та аудиту.
4. Протестуйте всі переходи через unit-тести.

Реалтайм-оновлення. Стек: Laravel Reverb, Soketi або Ably. Приватні канали на рівні проекту та задачі. Presence-канали показують, хто переглядає задачу. Оптимістичні оновлення на фронті через React Query.

// Frontend: Laravel Echo + React
const channel = window.Echo.private(`project.${projectId}`);
channel
  .listen('.task.updated', (e) => {
    queryClient.invalidateQueries(['tasks', e.task.id]);
  })
  .listen('.comment.created', (e) => {
    setComments(prev => [...prev, e.comment]);
  });

Які представлення та тайм-трекінг потрібні?

Мінімальний набір: Kanban-дошка (drag-and-drop через @dnd-kit/core, віртуалізація при 50+ картках), список з вкладеністю (tree-table, серверне сортування), діаграма Ганта (frappe-gantt або @dhtmlx/gantt, відображення залежностей), календарний вигляд (FullCalendar).

Тайм-трекінг. Глобальний таймер в UI, зберігає стан в localStorage, синхронізує з сервером. Дані логів зберігаються в таблиці з автоматично обчислюваним duration. При закритті вкладки — beforeunload зберігає поточний інтервал.

Як реалізувати ролі, сповіщення та пошук?

RBAC з project-scope ролями. System roles (admin, member) та project roles (owner, manager, developer, viewer, external). Використовуємо spatie/laravel-permission з прив'язкою до моделі Project. Гостьовий доступ через окремі токени.

Сповіщення — багатоканальні: email, push, in-app, Slack. Користувач налаштовує підписки в профілі. Технічно: черга через Laravel Queues / BullMQ, батчинг email-листів.

Пошук. PostgreSQL FTS через tsvector достатній до 200 000 задач. Для більшого обсягу — OpenSearch.

ALTER TABLE tasks ADD COLUMN search_vector TSVECTOR;
UPDATE tasks SET search_vector =
  to_tsvector('ukrainian', coalesce(title, '') || ' ' || coalesce(description, ''));
CREATE INDEX tasks_search ON tasks USING GIN(search_vector);

Як забезпечити продуктивність PM-системи?

Інтеграції з Git-репозиторіями, CI/CD, Slack/Teams, Confluence/Notion, Google Calendar будуються на OAuth 2.0, webhooks та REST API. Токени шифруються.

Що входить в роботу

Після завершення проекту ви отримуєте:

• Повний вихідний код системи з коментарями
• Документацію з архітектури, моделі даних, API
• Docker-конфігурації для розгортання
• Інструкції з експлуатації та резервного копіювання
• Навчання команди (до 3 сесій)
• Гарантійна підтримка 3 місяці

Орієнтовні терміни

Повний проект: 22–32 тижні. Ітераційний запуск через 10–12 тижнів — core-функціонал без Gantt та інтеграцій. Замовте оцінку проекту і отримайте оптимальний план.

Як ми гарантуємо якість

Наш досвід — 10+ років у розробці корпоративних систем. Кожен проект проходить рев'ю архітектури, навантажувальне тестування та аудит безпеки перед запуском. Гарантуємо стабільну роботу під навантаженням до 10 000 одночасних користувачів. Зв'яжіться з нами для отримання консультації. Отримайте розрахунок вартості вашого проекту.

Розробка SaaS-платформ

Ми знаємо цей біль напам'ять. Запускаєш MVP з авторизацією та підпискою, а через півроку впираєшся в архітектурні рішення, які не можна відкотити без переписування половини коду. Multi-tenancy, білінг, аудит логів, feature flags — кожен блок вимагає попереднього проектування. Ціна помилки при масштабуванні сягає десятків людино-місяців, а вартість рефакторингу архітектури після запуску — 500 000–1 000 000 грн.

За 8 років роботи над SaaS-продуктами ми перевірили на практиці, які рішення працюють, а які перетворюють підтримку на пекло. Нижче — архітектурні підходи, які використовуємо самі та рекомендуємо клієнтам.

Як забезпечити масштабованість SaaS-платформи?

Як ми будуємо multi-tenancy: ізоляція без оверхеду

Перше, що вирішуємо — схема розділення даних. Shared schema (tenant_id на кожній таблиці) — наш стандартний вибір для більшості проектів. Всі орендарі в одній базі, міграції застосовуються разом, операційна складність мінімальна. В Laravel реалізуємо через Global Scope:

protected static function booted(): void
{
    static::addGlobalScope('tenant', function (Builder $builder) {
        $builder->where('tenant_id', TenantContext::current()->id);
    });
}

Глобальний скоп — лише перший рівень захисту. Обов'язково додаємо Row-Level Security в PostgreSQL — вона спрацює, якщо додаток пропустить WHERE tenant_id = ?:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

Для enterprise-клієнтів, яким потрібна фізична ізоляція, виділяємо окрему базу. Такий гібридний підхід (shared + dedicated) використовується в 80% зрілих SaaS: базовий продукт на shared schema, преміум — на окремій інстанції. Ми впроваджуємо його з першого спринту, щоб не переписувати логіку пізніше.

Модель multi-tenancy описана у відкритих джерелах — рекомендуємо ознайомитися для розуміння компромісів.

Чому білінг — найнедооціненіший блок

Upgrade посеред розрахункового періоду, downgrade з відкладеним набранням чинності, прострочений trial, failed payment з grace period — Stripe Billing закриває 90% сценаріїв з коробки. Обов'язково обробляємо вебхуки (customer.subscription.updated, invoice.payment_failed) з ідемпотентним ключем — без нього retry на клієнті призведе до подвійного списання.

Для локальних ринків — ЮKassa або Tinkoff recurring. API менш зручні, але покривають вимоги законодавства.

Порівняння: використання Stripe замість самописного білінгу скорочує час розробки підписної логіки у 2,5 рази, а кількість багів — на 80% (дані з наших проектів). Це економить від 200 000 грн на етапі MVP.

Onboarding: як не втратити користувача до aha-moment

Технічно onboarding — це wizard з persistent станом, який не можна випадково пропустити. Таблиця onboarding_steps з чек-листом, middleware редиректить на незавершений крок. Після завершення — флаг в user settings, middleware вимикається.

Критичний нюанс: показуйте прогрес реального продукту, не абстрактні кроки. «Створіть перший звіт» замість «Завершіть крок 3 з 5». Ми використовуємо drip-кампанії через Customer.io або власну чергу з відкладеними jobs — якщо користувач виконав ключову дію, наступний лист не надсилається.

Feature flags та управління доступом

SaaS з тарифами вимагає гранулярного контролю. Не робіть if ($user->plan === 'pro') по всьому коду — через місяць він стане непідтримуваним. Натомість:

• Backend: Gate + Policy з перевіркою через таблицю features, пов'язану з планами.
• Frontend: контекст з флагами, що завантажується при ініціалізації додатку.
• Open-source інструменти: Unleash або Growthbook — UI для A/B-тестів та rollout.

Як захистити API від агресивних клієнтів

Rate limiting — must-have для публічного API. Один клієнт може покласти всіх інших. В Laravel використовуємо Redis з sliding window counter:

Кожна відповідь містить X-RateLimit-Remaining та X-RateLimit-Reset — клієнти розраховують на ці заголовки.

Аудит-логи та моніторинг: що, хто і коли

Без аудит-логу неможливо дізнатися, хто видалив проект або коли змінилися налаштування білінгу. Таблиця audit_logs з індексами по (tenant_id, created_at) та (subject_type, subject_id). В Laravel — Observer'и на ключових моделях.

class OrderObserver
{
    public function created(Order $order): void
    {
        AuditLog::create([
            'tenant_id' => $order->tenant_id,
            'user_id' => auth()->id(),
            'action' => 'created',
            'subject_type' => Order::class,
            'subject_id' => $order->id,
        ]);
    }
}

Моніторинг: Sentry для exception tracking, Grafana + Prometheus для метрик. Алерти на error rate > 5% та response time p95 > 2s.

Як організувати безпеку та аудит у SaaS?

Безпеку будуємо на трьох рівнях: транспорт (HTTPS + HSTS), доступ (OAuth 2.0 / OpenID Connect з обов'язковим JWT refresh), дані (шифрування чутливих полів на рівні додатку). Аудит логів доповнюємо retention політикою — логи зберігаються 90 днів для free-тарифу і 365 для enterprise. Контроль доступу реалізуємо через RBAC з таблицею roles та permissions, інтегровану з Gate.

Помилка в налаштуванні CORS або відсутність CSRF-токенів на публічному API — найчастіша вразливість у SaaS, яку ми виправляємо на аудиті.

Досвід нашої команди та гарантії

Над SaaS-платформами працюють інженери з 8+ річним досвідом, за плечима — 50+ проектів, від стартапів до enterprise з мільйонними навантаженнями. Ми даємо гарантію на архітектурні рішення: якщо обраний підхід не масштабується — перепроектуємо за свій рахунок.

Що ви отримуєте

• Документація архітектури: схеми, ERD, sequence diagrams.
• Налаштування CI/CD (GitHub Actions / GitLab CI).
• Доступи до репозиторію, стейджингу та продакшену.
• Навчання команди: 2–3 сесії з код-рев'ю та runbook.
• Post-launch підтримка 1 місяць.
• Гарантія на архітектуру: безкоштовний рефакторинг, якщо рішення не проходить за навантаженням.

Процес роботи

1. Discovery (1–2 тижні) — аудит поточної архітектури, скоуп MVP, пріоритети фіч.
2. Проектування (1 тиждень) — вибір стеку, схема multi-tenancy, план білінгу.
3. Розробка (4–12 тижнів) — спринти по 2 тижні, демо після кожного.
4. Тестування (1 тиждень) — навантажувальні тести під target навантаження, security audit.
5. Деплой та навчання (1 тиждень) — rollout, налаштування моніторингу, передача документації.

Орієнтири за термінами

Розробка SaaS-платформи — складний, але керований процес, якщо від самого початку закласти правильну архітектуру. Якщо ви плануєте запуск або масштабування продукту — замовте консультацію, щоб уникнути типових помилок. Вартість проекту розраховується індивідуально, зв'яжіться з нами — оцінимо за 2 дні. Замовте розробку під ключ: від проектування до деплою з гарантією архітектури. Перша година консультації — безкоштовно.