Podpis umowy online, jak wdrożyć u firmy usługowej bez papieru (2026)

TL;DR

Zamiast wątków mailowych ze skanami i „która wersja Worda jest aktualna”: generujesz umowę z szablonu, wysyłasz klientowi unikalny link, podpisuje w przeglądarce, system zapisuje PDF z audit trail, wysyła email transakcyjny i ustawia status w bazie. Dla umów B2B o usługi IT w Polsce zwykle wystarczy prosty podpis elektroniczny (intencja + logi + archiwum), podpis kwalifikowany (eIDAS) jest potrzebny tylko w wybranych branżach regulowanych. Poniżej: architektura API, bezpieczeństwo i uczciwy disclaimer prawny.

Dla kogo to jest

• Software house’ów, agencji i konsultingu sprzedających projekty na umowie o świadczenie usług / umowie o dzieło
• Zespołów mających już szablony (Word/Google Docs), ale chcących jednego źródła prawdy (HTML → PDF)
• Klientów B2B oczekujących startu projektu w dniach, nie w tygodniach od „proszę o skan z pieczątką”
• Firm budujących własny panel zamiast płatnego SaaS z limitami użytkowników

Fraza (SEO)

podpis umowy online, umowa elektroniczna firma, podpis klienta strona www, workflow umowy b2b, podpis elektroniczny umowa o dzieło, archiwum umów pdf

Problem, który rozwiązujesz

Typowy chaos B2B wygląda tak: oferta w PDF → negocjacje w mailu → Word v3_final_FINAL2.docx → skan bez czytelnej daty → brak wpisu, kto i kiedy zaakceptował klauzulę RODO. Każdy dzień opóźnienia to ryzyko utraty projektu i koszt administracyjny.

System online porządkuje to w pięciu krokach z jednym identyfikatorem umowy w bazie.

Workflow B2B, od szablonu do archiwum

1. Szablon umowy

Szablon trzyma pola zmienne: nazwa firmy, NIP, zakres, kwota, harmonogram, IP, klauzule RODO, numer wersji w stopce PDF. W DevStudio szablony obsługuje warstwa contract-templates, treść generowana programowo, nie ręcznie wklejana z Worda przy każdej sprzedaży.

2. Utworzenie rekordu i linku

Endpoint POST /api/contracts (oraz powiązany flow /api/create-contract-link) tworzy unikalny identyfikator umowy, status początkowy i metadane klienta. Admin nie wysyła pliku, wysyła link do strony /contract/[contractId].

3. Wysłanie do klienta

POST /api/contracts/[id]/send wysyła mail z linkiem (z rate limitem i logowaniem IP). Status przechodzi na sent_to_client. Klient widzi treść, checkboxy zgód i pole podpisu (canvas lub zapis ręki).

4. Podpis klienta

POST /api/contracts/[id]/sign przyjmuje signedData, weryfikuje że umowa jest w statusie sent_to_client, zapisuje podpis, IP (getClientIp), timestamp i generuje PDF przez pdf-lib. Po podpisie możliwy jest drugi etap, /api/contracts/[id]/admin-sign, gdy firma counter-signuje po kliencie.

5. Archiwum i powiadomienia

• GET /api/contracts/[id]/download-pdf, pobranie wersji z dwoma egzemplarzami / pełnym PDF
• POST /api/generate-contract, generacja PDF z podglądu (również z rate limitem)
• POST /api/send-contract-email, mail do klienta z potwierdzeniem (endpoint chroniony adminem, requireAdminApi)

Klient i firma mają ten sam numer umowy, datę podpisu i ścieżkę audytu w bazie, nie „ktoś miał plik na pulpicie”.

Mapa API, co za co odpowiada

Stos technologiczny: Next.js 15, Prisma, pdf-lib, nodemailer / warstwa transakcyjna SMTP. To nie jest „formularz z załącznikiem”, to mała aplikacja workflow osadzona obok strony marketingowej.

Podpis prosty vs kwalifikowany (eIDAS), bez prawniczego żargonu

Disclaimer prawny (ważne)

Ten artykuł nie stanowi porady prawnej. Przepisy i praktyka sądowa zależą od wartości kontraktu, branży i stron umowy. Przy kontraktach wysokiej wartości lub sektorze regulowanym skonsultuj treść umowy i formę podpisu z prawnikiem. Wdrożenie techniczne zapewnia ślad audytowy i proces, nie zastępuje oceny, czy dana forma podpisu jest wymagana w Twoim przypadku.

Dla typowej umowy o świadczenie usług między przedsiębiorcami w IT sensowny pakiet to: jasna klauzula o formie dokumentowej i podpisie elektronicznym, zgoda na składanie oświadczeń przez system, numer wersji dokumentu oraz archiwum po obu stronach.

Co musi mieć strona / aplikacja podpisów

HTTPS i role

Cały flow tylko po HTTPS. Dwie role: klient (publiczny link z tokenem/ID) vs admin (panel, podpis firmy, wysyłka maili). Endpointy administracyjne nie mogą być dostępne anonimowo.

Audit trail

Przy podpisie zapisuj co najmniej:

• identyfikator umowy i numer wersji szablonu,
• datę i godzinę (UTC w bazie, lokalny format w PDF),
• IP klienta (jak w sign/route.ts),
• hash lub treść zaakceptowanych checkboxów (RODO, regulamin).

To nie „szpiegowanie”, to dowód przebiegu przy sporze „nie podpisywałem tej wersji”.

Wersjonowanie PDF

Każda zmiana zakresu lub ceny = nowa wersja szablonu i nowy rekord / nowy link. Stopka PDF: Wersja szablonu 2026-05-28 / Nr umowy DS-2026-0142.

Email transakcyjny

Po signed: mail do klienta z numerem umowy, datą i linkiem do PDF (lub załącznikiem, zależnie od polityki storage). Osobne powiadomienie do zespołu sprzedaży (buildContractAdminSignedNotificationEmail).

Bezpieczeństwo, minimum, które nie jest opcjonalne

Token i ID umowy

Link /contract/[contractId] powinien używać długiego, losowego ID (UUID), nie sekwencyjnego id=123. Zgadnięcie URL = dostęp do treści umowy przed podpisem.

Rate limiting

W DevStudio endpointy podpisu, wysyłki i generacji PDF korzystają z checkEmailRateLimit(ip), odpowiedź 429 z Retry-After przy nadużyciu. Chroni to przed spamem podpisów i brute-force na publicznych API.

Wygaśnięcie i jednorazowość

Po podpisie status ≠ sent_to_client, ponowny sign zwraca błąd. Link nie powinien pozwalać na nieskończone edycje bez logu. Opcjonalnie: data ważności linku 7–14 dni w polu expiresAt.

Brak indeksowania w Google

Layout strony umowy ustawia m.in. X-Robots-Tag: noindex, nofollow, noarchive, umowy i dane klientów nie trafiają do indeksu wyszukiwarki. To standard przy dokumentach poufnych.

Ochrona endpointów admina

/api/send-contract-email wymaga requireAdminApi, przypadkowy POST z internetu nie wyśle maila w imieniu firmy.

Integracje, które warto połączyć później

• CRM / Notion / Slack, webhook po statusie signed (start projektu w kanale #delivery)
• Fakturowanie, faktura dopiero po signed, nie po „ustnej zgodzie”
• KSeF / księgowość, eksport metadanych umowy (numer, kwota, NIP)
• Dropbox / S3, długoterminowe archiwum PDF poza serwerem aplikacji

Prosty MVP bez CRM to nadal ogromna oszczędność czasu względem maili ze skanami.

Najczęstsze błędy wdrożenia

1. Wysyłanie Worda zamiast jednego generatora PDF, pięć wersji prawnej prawdy.
2. Brak klauzuli, że klik „Podpisuję” jest złożeniem oświadczenia woli w formie elektronicznej.
3. Ten sam link wielokrotnie używany bez zmiany statusu i logów.
4. Brak kopii PDF w skrzynce klienta, „gdzie jest umowa?” tydzień później.
5. Indeksowalne URL-e umów, wyciek metadanych w Google.
6. Podpis przed akceptacją zakresu (checkboxy poniżej podpisu zamiast nad).
7. Brak counter-sign firmy, gdy klient oczekuje dwustronnego PDF od razu.

Ile trwa wdrożenie?

Czasy zakładają gotowy szablon prawny od kancelarii, redakcja klauzul bywa dłuższa niż kod.

FAQ

Czy podpis na ekranie jest legalny w Polsce?

Przy umowach B2B między przedsiębiorcami, w praktyce rynkowej bardzo często tak, jako przejaw woli wraz z logami systemowymi i PDF. Wyjątki i wysoka wartość kontraktu → prawnik. Artykuł nie zastępuje konsultacji.

Czy to zastępuje DocuSign / Autenti?

Dla wewnętrznego flow B2B IT, często tak funkcjonalnie (link, podpis, PDF, mail). Dla ekosystemu prawniczego z podpisem kwalifikowanym i masową obsługą koncernów, porównaj TCO licencji vs. własny moduł na Next.js.

Co jeśli klient nie ma myszy do podpisu odręcznego?

Wystarczy checkbox + wpisanie imienia i nazwiska / stanowiska z zapisem w signedData, ważniejsza jest spójność procesu niż piękny SVG podpisu.

Gdzie trzymać PDF po latach?

Baza + object storage z backupami i polityką retencji zgodną z RODO (cel przetwarzania, usunięcie po okresie przechowywania). Sam email klienta to za mało na jedyny archiwum.

Czy chatbot i formularz kontaktowy to ta sama umowa?

Nie, lead z www to lead. Umowa to osobny rekord po akceptacji oferty. Łączenie ich w jednym mailu miesza marketing z prawnem.

Panel admina, co widzi zespół sprzedaży

Po wdrożeniu warto mieć widok listy umów: status (draft, sent_to_client, signed, …), data wysyłki, klient, kwota, link do PDF. Admin nie powinien edytować treści po wysłaniu do klienta bez nowej wersji, inaczej podpis dotyczy innego dokumentu niż ten w archiwum. W DevStudio operacje wrażliwe (np. ponowna wysyłka maila) idą przez endpointy z autoryzacją admina, nie przez publiczny link.

Normalizacja treści w PDF (pdf-lib)

Polskie znaki diakrytyczne w PDF wymagają czasem normalizacji lub osadzenia fontów, w kodzie podpisu stosowana jest funkcja zamiany znaków na ASCII-kompatybilne w treści generowanej do PDF, żeby uniknąć „pustych kwadratów” w umowie u klienta. To szczegół techniczny, ale od niego zależy profesjonalny wygląd dokumentu wysyłanego do księgowej klienta.

Porównanie z SaaS (DocuSign, Autenti, itp.)

Dla dziesiątek umów rocznie w IT własny moduł się zwraca; dla jednej umowy rocznie, SaaS lub nawet podpisowany PDF mailowo może wystarczyć.

RODO i role administratora

Umowa zawiera dane osobowe (reprzentant klienta, email, telefon). W polityce prywatności opisz cel (zawarcie umowy), podstawę (np. wykonanie umowy / prawnie uzasadniony interes), okres przechowywania PDF i logów. Po upływie terminu, procedura usunięcia lub anonimizacji w bazie. Link do podpisu nie powinien być indeksowany, już wspomniane noindex, oraz dostęp tylko dla posiadacza URL.

Podsumowanie

Podpis umowy online w firmie usługowej to workflow: szablon → API → link → podpis → PDF → email → status signed. Technicznie: Next.js API routes (contracts, sign, generate-contract, send-contract-email), pdf-lib, rate limit, noindex. Prawnie: dla typowego B2B IT zwykle wystarczy prosty podpis z dobrym audytem, przy wątpliwościach prawnik, nie blog. Zacznij od jednego szablonu i jednego happy path, rozszerzaj o admin-sign i CRM, gdy proces się sprawdzi.

Chcesz system podpisów u siebie?

• Skontaktuj się, omówimy szablony i integracje
• Aplikacje web, dedykowane moduły B2B w Next.js
• Zobacz realizacje, projekty z automatyzacją procesów