Doktally — Платформа за фактуриране и финансово управление

Накратко

Doktally е личен продукт, създаден да покрива реални нужди около фактуриране и финансово управление чрез практичен и модулен подход. Платформата комбинира работа с документи, справки, административни процеси и разширяема бизнес логика по начин, който остава ясен, лек и готов за развитие.

Подзаглавие

Продуктово ориентирана платформа за фактуриране, справки и оперативни процеси за фрийлансъри и малък бизнес.

Област

FinTech / Фактуриране / Операции за малък бизнес

Потребители

Фрийлансъри, самостоятелни професионалисти и малки компании, които имат нужда от практично фактуриране, работа с документи и справки без тежестта на голяма ERP система.

Роля

Основател / Product Engineer

Предизвикателство

Много системи за фактуриране покриват само базовия сценарий: създаване и изпращане на документ. Реалната работа обаче почти винаги включва повече — жизнен цикъл на документа, напомняния, прикачени файлове, справки, бъдещи данъчни процеси, административен контрол и възможност за адаптация. Doktally е създаден именно за тези нужди, без продуктът да става тромав и труден за поддръжка.

За какво отговарях

Продуктова концепция, backend архитектура, frontend имплементация, моделиране на домейна, дизайн на справки, admin UX, подход за deployment и дългосрочно развитие на продукта.

Подход

Built a maintainable Java/Spring Boot + Angular product with domain workflows shaped around real operational use.

Резултати

Изградена е работеща продуктова основа върху реални use case-и, с модулна архитектура, двуезична поддръжка, справки и структура, която може да се разширява към известия, лицензиране, ДДС процеси и други оперативни функционалности.

Подробности

Обзор

Doktally е продукт, който започнах, за да реша практичен проблем: исках система за фактуриране и финансово управление, която отразява реалната работа на независим професионалист или малък бизнес, а не само опростен демо сценарий.

Платформата е изградена около една проста идея: бизнес софтуерът трябва да подпомага реалната оперативна работа, а не само генерирането на документи. Това означава продуктът да поддържа администрация, справки, прикачени файлове, напомняния, бъдещи данъчни процеси и ясна структура, която може да се развива във времето.

Като личен продукт Doktally ми даде възможност да съчетая продуктово мислене, backend архитектура и admin-heavy frontend в една цялостна система.

Контекст

Повечето леки системи за фактуриране се справят добре с първата стъпка: създаване на документ.

Сложността идва след това:

• документите имат нужда от последващи действия
• трябва да се следят прикачени файлове
• трябва да се изпращат напомняния
• справките трябва да отразяват реалната дейност
• административните действия трябва да останат ефективни
• продуктът трябва да остане разбираем, дори когато обхватът му расте

Исках система, която остава фокусирана, но не се разпада в момента, в който процесът стане по-реалистичен.

Цели

Проектът имаше няколко паралелни цели:

• да изгради използваема основа за фактуриране върху реални процеси
• да запази архитектурата модулна и лесна за разширяване
• да поддържа admin-ориентиран UI, без той да се превърне в претрупан back office
• да създаде справки, които наистина са полезни за малки оператори
• да остави място за бъдещи модули като известия, лицензиране и данъчни процеси
• да остане подходящ за собствена употреба, но с мисъл и за бъдещ публичен SaaS продукт

Моята роля

Това е продукт, воден от основателя и изграден инженерно. Аз нося отговорност от край до край за:

• продуктовата посока
• техническата архитектура
• backend имплементацията
• frontend имплементацията
• моделирането на домейна
• дизайна на справките
• admin процесите
• подхода за deployment
• дългосрочната техническа еволюция

Тази отговорност означава постоянни компромиси между скорост, поддръжка, обхват и бъдеща разширяемост.

Подход към решението

Избрах модулна архитектура с Java и Spring Boot в backend-а, Angular във frontend-а и MongoDB за по-гъвкаво моделиране на домейна.

Платформата е създадена така, че да поддържа както днешните use case-и, така и бъдещи разширения, без текущият продукт да изглежда свръхинженерен.

flowchart TD
    A[Angular Client] --> B[Spring Boot API]
    B --> C[MongoDB]
    B --> D[RabbitMQ]
    B --> E[Document / Invoice Module]
    B --> F[Notification Module]
    B --> G[Reporting Module]

    E --> H[PDF / Attachments / Document Lifecycle]
    F --> I[Email Templates / Reminders]
    G --> J[Revenue / Operational Insights]

На ниво UI се фокусирах силно върху удобството за администрация. Продуктът съдържа форми, филтри, списъци, drilldown екрани, справки и домейн-специфични действия, затова frontend-ът трябваше да остане структуриран и лесен за навигация.

На ниво backend запазих системата достатъчно модулна, за да поддържа бъдещи възможности като:

• email процеси
• функционалности, контролирани чрез лицензиране
• финансови справки
• импорти и анализи, свързани с българското ДДС
• background processing за по-тежки или асинхронни действия

Ключови решения

1. Изграждане около реални процеси, а не само около ентитети

Вместо да мисля само в CRUD екрани, третирах продукта като набор от оперативни потоци:

• създаване и управление на документи
• проследяване на финансово състояние
• прикачане на поддържащи файлове
• генериране на полезни обобщения
• надграждане към напомняния и справки

Това направи системата по-реалистична още от самото начало.

2. Admin частта да бъде продукт, а не остатъчна мисъл

Много бизнес системи се провалят, защото административната част става хаотична. Тук целенасочено инвестирах в консистентен layout, tabbed editing, повторно използваеми UI модели и по-добра информационна плътност, така че продуктът да остане използваем и при растящ обхват.

3. Разширяемост вместо фалшива простота

Една система може да изглежда проста само защото игнорира трудните части. Аз предпочетох структура, която може да поеме бъдеща сложност без нужда от пренаписване.

Примерен процес

Една от важните идеи в Doktally е, че документът не е просто PDF, който се генерира веднъж. Той е част от по-дълъг процес.

sequenceDiagram
    participant U as User
    participant UI as Doktally UI
    participant API as Backend API
    participant DOC as Document Module
    participant NOTIF as Notification Module

    U->>UI: Create or update invoice
    UI->>API: Submit document data
    API->>DOC: Validate and persist document
    DOC-->>API: Stored document entry
    API-->>UI: Return updated state

    U->>UI: Trigger send action
    UI->>API: Request email sending
    API->>DOC: Resolve existing PDF / attachment
    API->>NOTIF: Send email using template and attachment
    NOTIF-->>API: Delivery result
    API-->>UI: Show success or failure

Този процес е важен, защото свързва бизнес данните, генерираните артефакти и комуникационните стъпки в едно последователно продуктово изживяване.

Предизвикателства

Баланс между обхват и продуктова дисциплина

Когато продуктът се изгражда от основателя, изкушението винаги е да се добавя още. Истинското предизвикателство е да се реши кое заслужава first-class място и кое трябва да почака.

При Doktally целта не беше да се създаде гигантски ERP. Целта беше да се изгради чиста оперативна платформа, която да расте в правилните посоки.

Богат UI без шум

Admin-heavy приложенията често се претоварват с бутони, колони, филтри и форми. Голяма част от работата беше в това UI-ът да остане разбираем, като същевременно запази достатъчно сила и гъвкавост.

Ранно мислене за справки

Справките са много по-лесни, когато домейн моделът е проектиран с тях предвид. Третирах reporting-а като базова възможност, а не като нещо залепено накрая.

Резултат

Doktally се разви в стабилна продуктова основа със следните силни страни:

• модулна backend структура
• бизнес-ориентиран admin UI
• справки, съобразени с реални процеси
• двуезична поддръжка на съдържание и продуктово представяне
• място за асинхронни процеси и бъдещи интеграции
• структура, подходяща първо за собствена употреба, но и разширяема към по-широк продукт

Проектът е и силен пример за начина, по който работя, когато държа целия цикъл: от продуктовата логика и системната структура до детайлите в имплементацията и UX решенията.

Какво бих подобрил следващо

Следващите приоритетни подобрения за мен са:

• по-дълбоко управление на известия и шаблони
• по-напреднали справки и dashboard-и
• по-силна автоматизация около жизнения цикъл на документите
• по-богати ДДС процеси и анализи
• продължаващо подобряване на admin UX и повторно използваеми table модели
• по-ясни граници за монетизация и пакетиране на публична версия

Извод

Doktally не е просто упражнение по програмиране. Това е инженерно усилие с продуктова форма, изградено върху реални оперативни нужди.

То показва как подхождам към софтуера, когато трябва да мисля отвъд кода:

• от какво реално имат нужда хората
• как се развиват процесите
• как архитектурата остава адаптивна
• как admin-heavy системите остават използваеми
• как един продукт може да остане стегнат, без да стане повърхностен

Технологии

Java, Spring Boot, Angular, TypeScript, MongoDB, RabbitMQ, Docker, PrimeNG, Keycloak

Ангажимент

PERSONAL_PRODUCT

Период

2024-03 – досега

• Проект