NASZA OFERTA · TWORZENIE APLIKACJI WEBOWYCH

Aplikacja webowa dla firmy, która wyrosła z arkuszy

Q: Czy DV buduje aplikacje pod RODO Art. 9 (medycyna), KNF (finanse) lub SOC2?

RODO Art. 9 (dane wrażliwe — medycyna, dane biometryczne): Tak. Baseline DV (encrypted at rest, audit log, RBAC, multi-factor auth) pokrywa core wymogi. Discovery (Etap 02) zawiera RODO gap analysis — co dodatkowo aplikacja potrzebuje (np. specific retention policies, consent management, DPIA support). Realnie 4-6 projektów RODO Art. 9 zrealizowanych, głównie medycyna i HR. KNF (sektor finansowy): Częściowo. Baseline aplikacji webowej DV pokrywa security i audit, ale specific KNF compliance (rekomendacje D, M, Z) wymaga często external compliance consultanta. DV pracuje w trybie collaboration — my budujemy aplikację, klient + KNF compliance firma walidują. 1-2 projekty fintech zrealizowane (nie pełny banking, ale adjacent — fintech B2B, lending platform). SOC2 / ISO 27001: Nie default. Te audyty wymagają operacyjnych procesów firmy (ciągłe monitoring, incident response procedures, employee training, physical security data center) — nie tylko aplikacja webowa. DV buduje aplikację z technicznymi kontrolami SOC2-ready (audit log, encryption, access control), ale certyfikacja jest po stronie klienta lub external SOC2 audit firmy. HIPAA / GDPR US compliance: Nie. DV pracuje na rynkach Polska / EU / Szwajcaria. Dla US healthcare compliance polecamy specjalistyczne firmy.

Q: Czy DV migruje istniejące aplikacje (PHP legacy, stary .NET, custom enterprise)?

Tak, ale selektywnie . Migracja legacy to często 60-80% budżetu nowej aplikacji, a output ma sens tylko jeśli istniejący system rzeczywiście blokuje biznes . Trzy scenariusze migracji które robimy: 1. Migracja UI/frontend, backend zostaje: Najczęstszy case. Stary monolit PHP/Java/.NET zostaje, dodajemy nowy frontend Next.js komunikujący się z istniejącym backend przez API. Czas: 8-12 tygodni. Ryzyko: niskie. ROI: szybki (klient widzi nowoczesny interface w 2-3 miesiące). 2. Migracja stopniowa (strangler pattern): Stary system zostaje w produkcji, nowe moduły w Next.js + Payload zastępują legacy moduły jeden po drugim. Czas: 12-24 miesiące. Ryzyko: średnie. ROI: rozłożony, mniejszy disruption biznesowy. 3. Pełna migracja (rebuild): Stary system zarchiwizowany (read-only), nowy system zastępuje 100% funkcjonalności. Czas: 16-32 tygodnie. Ryzyko: wysokie (data migration, user training, rollback strategy). ROI: długoterminowy, ale wymaga business case ROI 3-5 lat. Czego NIE robimy: Migracja stack'u którego DV nie używa w produkcji (Java legacy, Ruby on Rails legacy, custom mainframe) „Małe poprawki" w istniejącym legacy code'ie (freelancer scope) Rebuild bez clear business case (custom dla custom = fail)

Custom CRM, panel klienta, B2B portal, dashboard wewnętrzny, SaaS multi-tenant — gdy gotowe narzędzia (Excel, Pipedrive, Asana, Zapier) przestają skalować się razem z firmą. Aplikacja zaprojektowana pod Twój workflow, nie pod założenia generic SaaS-a — rozbudowywana iteracyjnie przez 3-5 lat, nie wymaga refactor po roku.

Większość firm zaczyna od gotowych narzędzi: Excel, podstawowy CRM, Zapier do integracji. Działa do skali kilkudziesięciu osób i kilku procesów. Powyżej tej skali zaczyna się odwrotna ekonomia — więcej godzin na manualne kopiowanie danych, więcej błędów operacyjnych, więcej narzędzi, których nikt nie używa w pełni.

Custom aplikacja webowa rozwiązuje to, czego gotowe narzędzia nie adresują: workflow specyficzny dla branży klienta, integracja między 5+ systemami w firmie, panel klienta z self-service 24/7, dashboardy zarządcze agregujące dane z całego ekosystemu. Większość naszych klientów aplikacji webowych to firmy 30-150 osób — Excel przestał wystarczać 6 miesięcy temu, ale gotowe SaaS nie pasują do procesu lub kosztują więcej niż custom build z 5-letnim horyzontem.

20+ lat IT · 50+ wdrożeń · od 30 000 zł · Polska / EU / Szwajcaria

NASZA OFERTA · TWORZENIE APLIKACJI WEBOWYCH

Aplikacja webowa dla firmy, która wyrosła z arkuszy

Custom CRM, panel klienta, B2B portal, dashboard wewnętrzny, SaaS multi-tenant — gdy gotowe narzędzia (Excel, Pipedrive, Asana, Zapier) przestają skalować się razem z firmą. Aplikacja zaprojektowana pod Twój workflow, nie pod założenia generic SaaS-a — rozbudowywana iteracyjnie przez 3-5 lat, nie wymaga refactor po roku.

20+ lat IT · 50+ wdrożeń · od 30 000 zł · Polska / EU / Szwajcaria

KIEDY WARTO · 4 SYGNAŁY

Kiedy aplikacja webowa zwraca się szybciej niż gotowy SaaS

Cztery sygnały, przy których custom aplikacja jest tańsza długoterminowo niż próba wciśnięcia procesu w gotowe narzędzia. Jeśli rozpoznajesz przynajmniej dwa — czas na rozmowę architektoniczną.

01WORKFLOW NIE PASUJE

Wdrożony SaaS wymusza zmianę procesu zamiast wspierać

Kupiłeś gotowy CRM, project management lub branżowy SaaS — zespół narzeka. Workflow firmy nie pasuje do założeń narzędzia, więc albo Excel wraca tylnymi drzwiami, albo proces został wykrzywiony żeby pasował do narzędzia.

Konkretne objawy:

Custom workflow wymaga 5+ workaround-ów w gotowym narzędziu
30%+ funkcji nieużywane bo nie pasują do branży/procesu
Pracownicy mówią „prościej zrobić to w Excelu"
Subskrypcje narzędzi do automatyzacji rosną, bo gotowy SaaS nie ma kluczowych integracji

Custom aplikacja: workflow w 100% pod proces firmy, jedna baza danych, jeden login, jedna logika.

02DATA SILOS

Dane między systemami przepływają przez ludzi, nie API

Zamówienie z marketplace kopiowane manualnie do księgowości. Lead z formularza www przepisywany do CRM. Faktura wprowadzana ponownie do raportu zarządczego. Każda operacja to 5-15 minut

ryzyko błędu.

Konkretne objawy:

3+ systemy w firmie, dane przepływają przez Excela/email/PDF
Pracownik backoffice spędza >20% czasu na manualnym kopiowaniu danych
Raporty zarządcze są spóźnione bo dane trzeba „ściągnąć"
Każdy nowy klient = setup w 4-5 systemach osobno

Custom aplikacja z API integration: synchronizacja w czasie rzeczywistym, single source of truth, raporty zarządcze automatyczne.

03SAMOOBSŁUGA 24/7

Klient B2B oczekuje samoobsługi, my obsługujemy mailowo

Klient B2B chce 24/7 dostępu: status zamówienia, historia faktur, dokumenty do pobrania, zgłoszenia reklamacyjne. Konkurencja już to ma. Wy obsługujecie mailowo — szybkość spada, koszty rosną, klient widzi was jako „mniej profesjonalnych".

Konkretne objawy:

Klient pyta „czy macie panel klienta?"
30%+ czasu zespołu obsługi to powtarzalne pytania o status
Zwroty/reklamacje generują 5+ maili tam i z powrotem
Konkurenci w branży mają portal klienta, wy nie

Custom panel klienta: redukcja obsługi powtarzalnej o 50-70%, sygnał profesjonalizmu rynkowego.

04DECYZJE NA DANYCH

Decyzje zarządcze na podstawie spóźnionych raportów Excel

Zarząd dostaje raporty miesięczne — przygotowanie zajmuje 3-5 dni roboczych analityka. Dane są spóźnione, decyzje o tydzień za późno. Real-time dashboard z agregacją z CRM, księgowości i magazynu rozwiązuje problem.

Konkretne objawy:

Raporty zarządcze przygotowywane manualnie, 1-3 dni pracy per raport
Zarząd pyta „jak nam idzie?" — odpowiedź wymaga 4 maili do różnych działów
Dane z 3+ systemów łączone w Excel za każdym razem od nowa
Pracownik analityki przeładowany pracą, której większość jest powtarzalna

Custom dashboard: real-time data z agregacją, self-service drill-down, alerty na anomalie.

↳ Jeśli nie rozpoznajesz żadnego z 4 sygnałów — gotowy CRM / project management / SaaS prawdopodobnie wystarczą i są tańsze niż custom aplikacja. Mówimy to wprost zamiast wciskać niepotrzebną inwestycję.

5 SCENARIUSZY · WYBIERZ TYP APLIKACJI

Co konkretnie budujemy

Każdy scenariusz to osobna sub-strona ze szczegółami: kiedy warto, typowe użycie, stack, proces, widełki cenowe. SaaS jako flagship — broader scope, generic case. Pozostałe 4 to specializations dla konkretnych potrzeb biznesowych.

01SAAS

SaaS multi-tenant — od MVP do produktu

Multi-tenant · Subskrypcje · Auth · Białe-label · Scaling-ready

Najszerszy scope w aplikacjach webowych — generic case dla firm które budują własny produkt SaaS lub wewnętrzną aplikację działającą jak SaaS dla wielu działów. Multi-tenant architecture od pierwszego dnia, subskrypcje (Stripe), auth z multi-factor, opcjonalnie białe-label dla resellerów.

Stack: Next.js + Payload + PostgreSQL + Stripe. Architektura modułowa pod 3-5 lat rozbudowy iteracyjnej.

Typowy projekt: 8-16 tygodni. Cena: od 50 000 zł.

02DASHBOARD

Dashboard zarządczy z real-time data

BI · Agregacja danych · Self-service drill-down · Alerty

Dla zarządów i działów operacyjnych potrzebujących real-time wglądu w dane firmy. Agregacja z CRM, księgowości, magazynu, produkcji. Self-service drill-down zamiast manualnych raportów Excel. Alerty na anomalie operacyjne. Eliminuje 3-5 dni pracy analityka miesięcznie.

Typowy projekt: 6-12 tygodni. Cena: od 30 000 zł.

03DASHBOARD

Dashboard zarządczy z real-time data

BI · Agregacja danych · Self-service drill-down · Alerty

Typowy projekt: 6-12 tygodni. Cena: od 30 000 zł.

04CUSTOM CRM

Custom CRM dla branż, których nie obsługuje gotowy SaaS

Workflow · Pipeline · Integracje · Branża-specific

Gdy Pipedrive, HubSpot i inne nie pasują do specyficznego workflow branży (medycyna, finanse, B2B niche, produkcja, logistyka). Custom pipeline, custom etapy, custom kalkulacje oferty. Jedna baza, jeden login, integracje z istniejącymi systemami firmy.

Typowy projekt: 8-14 tygodni. Cena: od 40 000 zł.

Dedykowana sub-strona w przygotowaniu — pełny opis i kalkulator dostępne wkrótce.

05B2B PORTAL

B2B portal partnerski dla firm 100-300 osób

Partnerzy · Distributors · Agenci · White-label · Multi-region

Dla firm rosnących skalą partnerskiej dystrybucji — portal dla agentów, dystrybutorów, partnerów regionalnych. Każdy partner widzi swoje dane (zamówienia, marże, materiały marketingowe), pełna izolacja per tenant. White-label dla co-branded operations.

Typowy projekt: 12-20 tygodni. Cena: od 80 000 zł.

Dedykowana sub-strona w przygotowaniu — pełny opis i kalkulator dostępne wkrótce.

↳ Lista nie jest zamknięta. Jeśli Twój przypadek nie pasuje do żadnego scenariusza (custom marketplace, wewnętrzna platforma branżowa, narzędzie pracownicze) — opisz w formularzu, wracamy z konkretami w 24-48h.

CO DOSTAJESZ · 4 KONKRETY APP-SPECIFIC

Co dostajesz w cenie aplikacji webowej DV

Cztery rzeczy w standardzie każdej aplikacji webowej DV — niezależnie czy to SaaS, portal klienta, dashboard czy custom CRM. Nie upselle, nie pakiety premium — baseline dla każdego projektu.

UX ZAPROJEKTOWANE POD BIZNES

UX dopasowane do realnego workflow, nie do design trendów

Większość aplikacji webowych ma UX „kopiowany z innych SaaS-ów" — sidebar nav, dashboard tiles, generic forms. Wygląda nowocześnie, ale nie pasuje do workflow firmy klienta. Pracownicy klikają więcej, nie mniej.

DV pracuje inaczej:

User research z 3-5 przyszłymi użytkownikami przed rozpoczęciem designu (Etap 02 procesu) — co realnie robią, jak długo, jak często
Wireframes testowane z użytkownikami przed kodem (klikalny prototyp Figma)
Design tokens jako CSS variables — spójność visualu, ale workflow-first
A/B testy najważniejszych flow po launch'u — iteracja na danych, nie zgadywanie

Konsekwencja: pracownicy adoptują aplikację w 1-2 tygodnie, a nie „uczymy się tego od 3 miesięcy".

MONITORING I ALERTY DLA WŁAŚCICIELA

Wiesz wcześniej niż użytkownik gdy coś nie działa

Aplikacja webowa różni się od strony — użytkownicy są z nią codziennie, sesje trwają godziny, błędy kosztują realne pieniądze (utracone zamówienie, zła kalkulacja, zaginięcie danych). Monitoring to nie "nice to have", to baseline.

Standard DV w każdej aplikacji webowej:

Sentry — error tracking z full stack trace + session replay (widzimy co user robił przed błędem)
Uptime monitoring co 5 minut — alerty SMS/email gdy aplikacja niedostępna >2 min
PostHog — product analytics + heatmapy + session recordings
Application Performance Monitoring (czas response, queries DB, bottlenecki)
Centralized logging z retention 30 dni + alerty na anomalie

Konsekwencja: błąd produkcyjny zgłaszamy My do Was. Fix typowo w 2-4h od incydentu. Twój zespół nie traci czasu na „ktoś mówi że nie działa, sprawdzimy".

ARCHITEKTURA POD 3-5 LAT ROZBUDOWY

Aplikacja, do której dodaje się funkcje, a nie przepisuje

Aplikacje webowe żyją 3-5 lat. Architektura zaprojektowana pod tę perspektywę, nie pod „byle launch w 8 tygodni":

Monorepo structure (apps/web, apps/admin, packages/database, packages/ui) — dodanie panelu admin lub mobile app bez przepisywania
TypeScript strict mode + Zod validation — kontrakty między modułami sprawdzane compile-time (błędy łapane przed deployment)
Database migrations w wersjonowanym kodzie — schema evolution bez "ALTER TABLE w produkcji"
Multi-tenancy ready (nawet single-tenant aplikacje) — dodanie drugiego klienta to konfiguracja, nie refactor
Feature flags + A/B testing infrastructure od pierwszego dnia

Konsekwencja: rozbudowa za 2 lata to dodanie funkcji w 2-4 sprintach, nie 6-miesięczny refactor całego systemu.

AUTH I SECURITY W STANDARDZIE

Bezpieczeństwo niewidoczne dla użytkownika, ale obecne

Aplikacja webowa to dane klientów Twojej firmy — naruszenie oznacza realny problem prawny (RODO), reputacyjny i operacyjny. Security baseline w standardzie:

Authentication: NextAuth/Auth.js lub Clerk (multi-factor 2FA, passwordless, SSO opcjonalnie)
Authorization: role-based access control (RBAC) z poziomu kodu i bazy danych (defense in depth)
Encrypted at rest (PostgreSQL TDE) + encrypted in transit (TLS 1.3)
OWASP Top 10 covered: SQL injection, XSS, CSRF, broken auth, security misconfiguration
Rate limiting na API endpoints (zabezpieczenie przed brute-force i DDoS)
Audit log w bazie: kto, kiedy, co zmienił (RODO compliance)

Konsekwencja: aplikacja przechodzi audit security klienta enterprise bez panicznego refactoru. Compliance team klienta dostaje dokumentację (security checklist) w handoff.

↳ Te 4 elementy są w cenie aplikacji webowej DV od pierwszego projektu — nie "premium package". Software house oferujący je jako upsell to red flag — w aplikacji webowej (vs strona) są one baseline, nie dodatkiem.

STACK · 4 WARSTWY ARCHITEKTURY

Stack technologiczny dla aplikacji webowych

Stack aplikacji webowej dobierany pod wymagania biznesowe — nie ma „domyślnego stack'u" w DV. Cztery warstwy poniżej (frontend, backend, auth, infrastruktura) z najczęstszymi wyborami i kryteriami decyzji per projekt.

01FRONTEND

Next.js + React Server Components + Tailwind

Default frontend dla aplikacji webowych moze być: Next.js z App Router i React Server Components. Tailwind CSS + shadcn/ui jako component library. React Hook Form + Zod do walidacji formularzy.

Dlaczego ten stack:

Next.js App Router — server components redukują JavaScript bundle 30-60% vs pure client React, lepszy LCP/TTI
Tailwind + shadcn/ui — design tokens jako CSS variables, component library copy-paste (nie node_modules dependency)
Zod walidacja — single source of truth dla types frontend + backend + database

Kiedy odstąpienie:

Vue / Nuxt — gdy klient ma już Vue ekosystem w firmie
Astro — dla aplikacji content-heavy z minimal interaktywności (dokumentacja, portal informacyjny)
Angular — enterprise klienci z istniejącą bazą Angular

W 90% projektów aplikacji webowych DV: Next.js. Pozostałe 10% zależy od klienta.

02BACKEND I DATABASE

Node.js + TypeScript + PostgreSQL + Prisma

Backend dla aplikacji webowych można zrealizować na podstawie: Next.js API Routes (serverless functions) lub dedykowany Hono/Fastify dla high-throughput API. Database: PostgreSQL z Prisma ORM. Background jobs: BullMQ

Redis (gdy potrzeba) lub Inngest (serverless background tasks).

Dlaczego PostgreSQL:

ACID transactions — zero ryzyka utraty danych
JSONB columns — flexibility NoSQL, ale w relacyjnej bazie
Row-level security — multi-tenancy ready bez application-layer hacks
Production proven — od 1996 roku, używany przez Stripe, Reddit, Instagram

Dlaczego Prisma:

Type-safe queries — błąd w queryach łapany compile-time
Auto-generated migrations z schema diff
Studio (GUI dla bazy) w developerce, prod-safe w produkcji

Alternatywy considered: Drizzle (lżejszy ORM, edge-deployment), TypeORM (legacy projekty), raw SQL (gdy Prisma constraint).

03AUTH I MULTI-TENANCY

Auth dobierany pod model biznesowy aplikacji

Auth nie ma jednego "default'a" w aplikacjach webowych — zależy od modelu biznesowego:

Single-tenant (jedna firma, wielu pracowników):

NextAuth/Auth.js + email magic links lub OAuth (Google, Microsoft) — najprostsze, zero vendor lock-in
Role-based access control z bazy (RBAC) — admin/user/viewer

Multi-tenant SaaS (wielu klientów, każdy z własnym workspace):

Clerk lub WorkOS — gotowe rozwiązania z multi-org support, SSO, SCIM provisioning
Custom rozwiązanie na NextAuth (gdy budget tight lub specific wymogi)

B2B portal z partnerami:

SSO (Single Sign-On) z systemu klienta — SAML 2.0 lub OAuth
Provisioning automatyczny z HR systemu klienta

Auth security baseline (każda aplikacja):

Multi-factor 2FA opcjonalne dla użytkownika
Rate limiting na login endpoints (brute-force protection)
Audit log każdego logowania (RODO compliance)
Sesje z secure HttpOnly cookies

04 INFRASTRUKTURA I DEPLOYMENT

Infrastruktura dobierana pod skalę i wymogi

Najczęstsze scenariusze deployment aplikacji webowych DV:

VPS — 80% projektów polskich klientów:

VPS — koszt 80-200 zł/mies.
Docker containers, Traefik load balancer, automated SSL
Database PostgreSQL na tym samym VPS lub osobny (zależnie od skali)
Backup codziennie + retention 30 dni

Cloud (AWS / GCP / Azure) — 15% projektów:

Gdy klient ma już ekosystem chmurowy (Azure AD, AWS S3, GCP BigQuery)
Architektura serverless (Lambda/Cloud Functions) dla event-driven workflows
Managed database (RDS/CloudSQL) — wyższy koszt, ale zarządzane przez cloud provider

Vercel + Neon/Supabase — 5% projektów:

Globalny edge network — gdy aplikacja ma użytkowników na 3+ kontynentach
Zero DevOps overhead — automated preview deployments per PR
Trade-off: koszt rośnie nieliniowo przy skali (>200k MAU)

CI/CD każda aplikacja:

GitHub Actions — automated tests + build + deploy do staging po każdym merge
Production release manualne po code review + acceptance testing

↳ Stack opinionated. Zmiana defaultu (np. Vue zamiast React, Cloud zamiast VPS) wymaga uzasadnienia w Etapie 01 procesu — nie zmieniamy stack'u „bo klient woli" bez analizy konsekwencji długoterminowych.

PROCES · 5 ETAPÓW · 8-16 TYGODNI5 etapów

Od konsultacji do produkcji — etapami

Każdy projekt aplikacji webowej DV przechodzi przez 5 etapów. Czas trwania zależy od skali (8 tygodni dla portalu klienta, 16+ dla SaaS multi-tenant), ale struktura jest stała. Decyzje architektoniczne zapadają na etapach 1-2 — nie po fakcie *„zapomnieliśmy o auth multi-tenant"*.

1-2 tygodnie · bezpłatnie

KONSULTACJA ARCHITEKTONICZNA

Pierwsza rozmowa (60-90 min) + 1-2 follow-up sesje. Mapujemy: jakie procesy biznesowe aplikacja ma wspierać, jakie systemy istnieją w firmie (CRM, ERP, księgowość), jak wygląda przyszły roadmap funkcjonalności (3-5 lat). Build/buy decision — weryfikujemy czy custom faktycznie ma sens vs gotowy SaaS.

Output: ADR (Architectural Decision Record) v0 + decyzja stack'u (frontend / backend / database / auth / infrastructure) z 2-3 alternatywami per warstwa. Każda decyzja ma uzasadnienie biznesowe.

2-3 tygodnie · płatny deliverable

DISCOVERY I SPECYFIKACJA

Discovery deep-dive specific dla aplikacji webowej: user research (3-5 wywiadów z przyszłymi użytkownikami), mapowanie data model (jak aplikacja organizuje dane), specyfikacja integracji API (które systemy zewnętrzne, jakie endpointy, częstotliwość sync, error handling), security model (auth, RBAC, multi-tenancy isolation jeśli SaaS).

Output: 4 dokumenty heritage tabular:

ERD (Entity Relationship Diagram) — schema bazy danych
API contract (OpenAPI 3.0 spec)
Integration map — które systemy zewnętrzne, jakie operacje
User stories + acceptance criteria — testowalne wymagania

Dla SaaS multi-tenant dodatkowo: tenant isolation strategy (row-level security vs schema-per-tenant vs database-per-tenant).

2-4 tygodnie

UX/UI + PROTOTYP TESTOWANY

Wireframes low-fidelity dla wszystkich kluczowych user flows (login, główne CRUD operations, raporty). Następnie design tokens i high-fidelity makiety w Figma. Klikalny prototyp testowany z 3-5 użytkownikami przed kodowaniem — identyfikujemy 60-70% UX issues zanim stają się tech debt.

Dla aplikacji z istniejącym design system klienta (po brandingu DV lub innym dostawcy) — adaptujemy do istniejących wytycznych zamiast tworzyć od zera.

Klikalny prototyp Figma + design tokens jako CSS variables gotowe do importu w Tailwind config. Zero hand-translation design → kod. User testing przed kodowaniem = redukcja re-work o 40-60% w Etapie 04.

4-12 tygodni · sprinty 2-tygodniowe

DEVELOPMENT + STAGING OD DNIA 1

Najdłuższy etap. Pracujemy w 2-tygodniowych sprintach z review po każdym sprincie. Staging environment od pierwszego sprintu — klient testuje feature N+1 podczas pracy nad N+2, feedback loop 1 tydzień zamiast 3-miesięcznego big-bang launch'u.

MVP scope: core user journey + critical integrations. Funkcje secondary (raporty advanced, edge case handling, admin panel deluxe) — po MVP launch'u na podstawie realnych user feedback.

Continuous deployment do staging. Code quality w CI/CD: TypeScript strict, ESLint, Vitest unit testy, Playwright E2E dla critical paths (login, payment, form submit, API contract). Merge blocked jeśli nie przechodzi standards.

Każdy PR = preview deployment z unique URL — klient testuje zmiany izolowane od main staging.

Launch + 30 dni stabilizacji

LAUNCH + MONITORING + STABILIZACJA

Production deployment + monitoring stack konfigurowany przed launchem (Sentry, Uptime, PostHog, APM, centralized logging). Handoff session 30-45 min: architektura, deployment process, jak debug-ować produkcję, jak push'ować zmiany. 30 dni stabilizacji w cenie (drobne poprawki, optymalizacje, fixy bug'ów odkrytych w produkcji).

Po stabilizacji 3 opcje:

Koniec współpracy — zero lock-in, kod Twój
Opieka techniczna abonament
Rozbudowa kolejnych funkcji

Handoff dokumentacja heritage tabular:

README + setup instructions (local dev w 30 min)
ADR (Architectural Decision Records) — dlaczego ten stack
Deployment runbook (jak deployować, jak rollback, jak debug produkcji)
Database schema docs + migrations history
Integration runbooks (jak skonfigurować Stripe webhooks, jak rotate API keys, jak debug failed sync)
Monitoring playbook — jakie alerty znaczą co, kiedy wakeup-on-call (jeśli aplikacja krytyczna)

HARMONOGRAM PROJEKTU APLIKACJI WEBOWEJ

8-16 tygodni

ŁĄCZNIE

8-12 tygodni

PORTAL KLIENTA / DASHBOARD

12-20+ tygodni

SAAS MULTI-TENANT

↳ Konkretny harmonogram po Discovery (Etap 02). Projekty SaaS enterprise (multi-region, compliance audit, dedicated support) — 20+ tygodnie. Konsultujemy indywidualnie.

CENNIK · 3 TIER'Y APLIKACJI WEBOWEJ

Ile kosztuje aplikacja webowa

Każdy projekt wycenianego indywidualnie po Discovery. Poniżej 3 tier'y skali typowej dla aplikacji webowych DV + kalkulator do oszacowania własnego projektu w 4 minuty.

01MAŁA

30 - 60 tys. zł

Czas: 6-8 tygodni

Pojedynczy moduł, 1-2 role użytkowników

1-2 role użytkowników (np. admin + user)
5-15 ekranów core
1-2 integracje API (np. Stripe + email)
Single-tenant architecture
Auth standard (NextAuth/Clerk)
Monitoring stack (Sentry + Uptime + PostHog)

02ŚREDNIA

60 - 120 tys. zł

Czas: 8-12 tygodni

3-5 ról, integracje, prosty multi-tenant

3-5 ról użytkowników z RBAC
15-40 ekranów core
3-5 integracji API (CRM + księgowość + płatności + email + analytics)
Multi-tenant ready (single-tenant deploy, ale architektura pod skalowanie)
Auth z multi-factor + audit log
Background jobs (queue processing, scheduled tasks, email sending)
Pełny monitoring + alerts

03ZŁOŻONA

120 - 300+ tys. zł

Czas: 12-20+ tygodni

Multi-tenant SaaS, compliance, advanced features

Multi-tenant SaaS architecture (row-level security lub schema-per-tenant)
5+ ról użytkowników z complex RBAC + custom permissions
40+ ekranów core
5-15 integracji API + webhooks bidirectional
Advanced features: białe-label, custom fields per tenant, workflow engine, reporting builder
Compliance ready (RODO Art. 9, KNF, audit trail)
Real-time collaboration (WebSocket/SSE)
Subskrypcje (Stripe billing) + usage-based pricing

Co najmocniej decyduje o cenie aplikacji webowej

Honest scope:

Hosting i infrastruktura w produkcji (VPS 80-200 zł/mies., cloud per usage, dedicated od 500 zł/mies.)
Monitoring tools — Sentry, PostHog, Uptime monitoring (Free dla małej skali, dalej od ~$25/mies. per tool)
External services płatne per użycie (Stripe 1.4-2.9% per transaction, Twilio per SMS, OpenAI per token, email delivery od 50 zł/mies.)
Domeny + SSL (~100 zł/rok)
Marketing kampanii (App Store Optimization, ads, content)
Treści (copywriting, grafika produktowa) — możemy wskazać sprawdzonych dostawców

Long-term koszty: zwykle 8-15% rocznie wartości projektu na hosting + opieka techniczna + drobne rozbudowy.

Czego nie obejmują nasze widełki

Heritage scope — co poza naszym obszarem pracy:

Lean MVP za 10-20 tys. zł — przy tym budżecie powstaje zwykle throwaway code. Lepsze opcje: no-code (Bubble, FlutterFlow) jako pierwszej walidacji, freelancer senior z portfolio, akcelerator startupowy z built-in tech support.
Custom enterprise z budżetami 1mil. zł — multi-region failover, custom hardware, dedicated support team 24/7 — pasują większe firmy konsultingowe (100+ osób software house).
Migracja legacy enterprise systems (mainframe, JEE legacy, custom ERP-y stare 15+ lat) — DV nie pracuje z legacy stack'iem.
Pojedyncze poprawki w istniejącej aplikacji innej agencji — pracujemy projektowo (Discovery → Wdrożenie → Long-term opieka), nie godzinowo na drobnice.

Jeśli Twój projekt mieści się w powyższych kategoriach — mówimy to wprost zamiast brać projekt którego nie zrobimy optymalnie.

Co NIE jest w cenie projektu

Honest scope:

Hosting i infrastruktura w produkcji (VPS 80-200 zł/mies., cloud per usage, dedicated od 500 zł/mies.)
Monitoring tools — Sentry, PostHog, Uptime monitoring (Free dla małej skali, dalej od ~$25/mies. per tool)
External services płatne per użycie (Stripe 1.4-2.9% per transaction, Twilio per SMS, OpenAI per token, email delivery od 50 zł/mies.)
Domeny + SSL (~100 zł/rok)
Marketing kampanii (App Store Optimization, ads, content)
Treści (copywriting, grafika produktowa) — możemy wskazać sprawdzonych dostawców

Long-term koszty: zwykle 8-15% rocznie wartości projektu na hosting + opieka techniczna + drobne rozbudowy.

Policz koszt aplikacji webowej Opisz swój projekt

↳ Widełki na podstawie 50+ wdrożeń aplikacji webowych DV z ostatnich 3 lat. Ostateczna cena ±15% po Discovery (Etap 02). Projekty SaaS enterprise (multi-region, compliance branżowy, custom hardware) konsultujemy indywidualnie.

CO ODRÓŻNIA NAS · 3 RZECZY APP-SPECIFIC

3 rzeczy, które robimy inaczej w aplikacjach webowych

Niezależnie od tier'u (mała / średnia / złożona) trzy rzeczy poniżej są w cenie i w standardzie każdej aplikacji webowej DV. Software house oferujący je jako *„premium add-on"* w aplikacji webowej (vs strona) to red flag.

MULTI-TENANCY READY

Architektura multi-tenant nawet dla single-tenant projektów

Większość software house buduje aplikacje single-tenant „bo klient ma jedną firmę". Konsekwencja: gdy klient za 18 miesięcy chce dodać drugiego klienta, drugą markę, drugi region — 6-miesięczny refactor całej bazy danych i systemu auth.

DV pracuje inaczej. Każda aplikacja webowa zaprojektowana multi-tenant ready od pierwszego sprintu, nawet jeśli deploy jest single-tenant:

Database schema z tenant_id w każdej tabeli (nawet dla single-tenant — tenant_id = '1')
Row-level security (RLS) w PostgreSQL — izolacja danych na poziomie bazy, nie aplikacji
Tenant routing (subdomain lub path-based) — gotowy do aktywacji w 1-2 sprintach
Per-tenant config (logo, primary color, feature flags, pricing plans) — schema gotowa, UI panel dodawany on-demand
Middleware auth z tenant context — request zawsze zna swojego tenant'a

Konsekwencja: dodanie drugiego klienta za 2 lata to konfiguracja, nie refactor. Białe-label dla resellerów = 1-2 sprinty pracy, nie 6 miesięcy. Najczęściej używane przy konwersji single-tenant SaaS → multi-tenant po pierwszych klientach enterprise.

PRODUCTION-READY

Staging od sprintu 1, monitoring przed launchem, zero „big bang"

Typowe software house: development w izolacji, „pokazujemy MVP za 8 tygodni". Klient widzi aplikację dopiero po launch, łapanie issues w produkcji, panic mode przez pierwsze 2-4 tygodnie po go-live.

DV pracuje inaczej:

Staging environment od sprintu 1 — link aktualny zawsze, klient testuje feature N+1 podczas pracy nad N+2
Continuous deployment — każdy merge do main = auto-deploy do staging w 5-10 min
Preview deployments per PR — każdy pull request = unique URL z izolowanym deployment
Code quality w CI/CD — TypeScript strict, ESLint, Vitest unit testy, Playwright E2E dla critical paths. Merge blocked jeśli nie przechodzi standards
Monitoring stack konfigurowany przed launch'em — Sentry, Uptime, PostHog, APM, centralized logging. Nie "dodamy po launch'u", tylko "działa przed pierwszym userem"

Konsekwencja: launch jest non-event. Klient testował aplikację 8 tygodni przed go-live, monitoring łapie błędy zanim user zauważy, fix typowo 2-4h od incydentu. Zero panic mode w pierwszych tygodniach produkcji.

CODE OWNERSHIP

Kod w Twoim repo od pierwszego sprintu, zero proprietary DV libraries

Vendor lock-in w aplikacjach webowych to większy problem niż w stronach. Aplikacja jest fundamentem operacji firmy — koszt zmiany dewelopera może wynieść 50-100% kosztu ponownego wdrożenia. Software house, świadomie lub nieświadomie, tworzy zależności trudne do złamania.

DV pracuje inaczej od pierwszego sprintu:

Pełny kod źródłowy w Twoim GitHub/GitLab — od pierwszego commit, nie po launch, nie po ostatniej fakturze
Twoja licencja, Twoja własność intelektualna — zero klauzul „DV zachowuje prawa do kodu" w umowie
Open-source / standard frameworks tylko — Next.js, Payload, PostgreSQL, Stripe — zero proprietary DV libraries których nie ma na npm
Zero hidden integrations — każda zewnętrzna integracja ma audit trail w kodzie + dokumentację jak ją skonfigurować pod własnym kontem klienta
Handoff dokumentacja w cenie — README + ADR + deployment runbook + database schema docs + integration runbooks (6 dokumentów heritage tabular)

Konsekwencja: klient z aktywnym deweloperem in-house odnajdzie się w kodzie w 1-2 tygodnie. Klient zmieniający dewelopera/agencję po 2 latach nie traci miesięcy na „rozszyfrowanie". Realne case z naszej praktyki: 2 klientów po 18-24 miesiącach przeszło na in-house team — kod się przeniósł bez problemów.

↳ Te 3 elementy są w cenie aplikacji webowej DV od pierwszego projektu. Software house oferujący je jako „enterprise tier" lub „premium add-on" — sygnał że nie są dla zespołu priorytetem i klient płaci osobno za rzeczy które powinny być standardem.

DLA KOGO DV · I DLA KOGO NIE

Dla kogo budujemy aplikacje webowe — i dla kogo nie

DV dobrze pracuje z 3 typami klientów aplikacji webowych. Dla 3 typów projektów polecamy gdzie indziej — gotowy SaaS, freelancer lub większe software house. Honest scope filter zanim zaczniemy rozmawiać.

Firma 30-150 osób, custom system jako must-have

Twój sweet spot u DV. Excel/gotowy CRM przestał wystarczać 6+ miesięcy temu, ruch w firmie wymaga dedykowanej aplikacji (custom CRM, panel klienta, B2B portal, dashboard wewnętrzny, SaaS dla wewnętrznych działów). Budżet 50-150 tys. zł na pierwszy projekt, decision cycle 2-6 miesięcy.

Typowe branże: usługi profesjonalne (prawne, medyczne, finansowe), B2B SaaS dla niszowych rynków, e-commerce z custom workflow, producenci z eksportem, firmy usługowe z sieciami lokalizacji.

Co Ci dajemy: dedykowaną aplikację pod Twój workflow, multi-tenant ready architecture od dnia 1, monitoring i opieka techniczna long-term (450-1500 zł/mies.).

Gotowy SaaS pokrywa 70%+ Twoich potrzeb

Custom aplikacja webowa to inwestycja długoterminowa (50-300k zł + 5-15% rocznie utrzymania). Jeśli gotowy SaaS pokrywa większość potrzeb — kup, nie buduj.

Najczęstsze sytuacje gdy mówimy „kup gotowy SaaS":

CRM dla 10-30 osób — Pipedrive, HubSpot Free, Bitrix24 starter
Project management — gotowy project management SaaS, branżowy SaaS (np. dla architektów, prawników)
Mailing automation — Brevo, Mailchimp, ActiveCampaign
Bookingi/rezerwacje — Calendly, Cal.com, branżowy SaaS
Helpdesk/ticketing — gotowe rozwiązania od ~200 zł/mies.

W 20-minutowej konsultacji architektonicznej DV przeprowadzi Cię przez build/buy decision. 15-20% rozmów kończy się rekomendacją „nie buduj, kup gotowy SaaS X".

Startup post-MVP, refactor lub rebuild pod scale

Macie validated business case, pierwsze przychody, ale MVP zbudowane na no-code (Bubble/FlutterFlow) lub w throwaway code zaczyna pękać. Potrzebujecie production-ready system pod scale (100+ aktywnych użytkowników, multi-tenant, billing).

Budżet 80-200 tys. zł na refactor/rebuild + plan rozbudowy iteracyjnej. Decision cycle 1-3 miesiące. Series A za 6-12 miesięcy = aplikacja musi być due-diligence ready (kod quality, dokumentacja, security baseline).

Co dostajecie u DV: production-ready stack od pierwszego dnia, multi-tenant architecture, monitoring + alerts, due-diligence documentation w handoff.

Lean MVP za 10-20 tys. zł / proof-of-concept w tydzień

Jeśli budżet to 10-20 tys. zł i potrzebujesz aplikacji żeby zwalidować hipotezę biznesową (nie żeby produkcyjnie działać dla 100+ klientów) — DV to overkill. Naszą minimalną wartością projektu jest 30 tys. zł (Tier 1 mała aplikacja), bo poniżej tego budżetu nie zbudujemy aplikacji która ma sens biznesowy long-term.

Polecane alternatywy:

No-code platformy — Bubble (najsilniejszy dla web apps), FlutterFlow (mobile + web), Glide (proste internal tools)
Freelancer senior z portfolio podobnych projektów (Useme, Bulldogjob, polskie społeczności tech)
Akcelerator startupowy z built-in tech support (PARP Platformy startowe, Startup Booster Poland — dofinansowanie)

Wracaj do nas gdy MVP zwaliduje hipotezę biznesową i potrzebujesz production-ready system pod scale (100+ użytkowników, multi-tenant, SLA, compliance).

Firma 100-300 osób, outsourcing modułu większego systemu

Macie internal tech team, ale przeciążeni — szukacie partnera do dedykowanego modułu aplikacji (portal partnerski, system rezerwacji, B2B marketplace, custom integration layer dla istniejącego ERP). Budżet 100-300 tys. zł, decision cycle 3-9 miesięcy z procesem zakupowym (RFP, NDA, DPA).

Co dostajecie u DV: zewnętrzny moduł zaprojektowany pod istniejącą architekturę, dokumentacja techniczna handover-ready dla Waszego in-house teamu, kod w Waszym repo, kontrakt z klauzulami enterprise compliance.

Enterprise 500+ pracowników, budżet 1+ mil. zł, multi-region

Dla projektów enterprise z wymaganiami: multi-region failover (deployment w 3+ regionach), custom hardware integration (IoT, embedded, dedicated GPU), dedicated support team 24/7 z SLA 99.99%, compliance audit (SOC2, ISO 27001, HIPAA), zaawansowana ML/AI infrastructure z proprietary models — DV to za mały zespół.

Pasują większe firmy konsultingowe (100+ osób software house polskie/międzynarodowe) lub direct hire enterprise dev team.

Nasz sweet spot: aplikacje webowe do 300 tys. zł budżetu, zespoły do 300 osób, scope 1-2 systemy core. Powyżej tej skali pracujemy z Wami tylko jako dostawca konkretnego modułu — nie głównym wykonawcą całej platformy.

↳ Jeśli pasujesz do jednego z 3 profili po lewej — następny krok to konsultacja architektoniczna (60-90 min, bezpłatnie). Jeśli mieścisz się w 1 z 3 sytuacji po prawej — dziękujemy za czas poświęcony na tę stronę. Polecamy się z polecenia firm, z którymi pracowaliśmy lub które sprawdziliśmy na rynku.

FAQ · 7 PYTAŃ O APLIKACJE WEBOWE

Pytania, które dostajemy w fazie konsultacji

Pytania specific dla aplikacji webowych — multi-tenancy, scaling, security, compliance, refactor z legacy. Pytania ogólne o współpracę z DV — w /nasza-oferta Blok FAQ. Pytania o software w ogóle — w /tworzenie-oprogramowania Blok FAQ.

01MULTI-TENANCY
Kiedy aplikacja powinna być multi-tenant, a kiedy single-tenant wystarczy?

Trzy kryteria decyzyjne:

Czy aplikacja będzie obsługiwać >1 klienta/zespół/markę w przyszłości 3-5 lat?

Tak (nawet hipotetycznie) → multi-tenant ready od dnia 1
Nie pewne → multi-tenant ready architecture, ale single-tenant deploy (DV default)
Definitywnie nie → single-tenant (rzadkie w praktyce)

Czy aplikacja ma kiedyś być białe-label dla resellerów?

Tak → multi-tenant required, custom branding per tenant
Nie → single-tenant ok

Compliance wymóg izolacji danych między klientami?

Tak (medycyna RODO Art. 9, finanse KNF) → schema-per-tenant lub database-per-tenant
Standard biznes → row-level security w PostgreSQL wystarcza

DV default: każda aplikacja webowa ma multi-tenant ready architecture (tenant_id w schema, RLS), nawet jeśli deploy jest single-tenant. Konwersja single → multi w 1-2 sprintach zamiast 6-miesięcznego refactoru.

02SCALING I PERFORMANCE
Co się stanie gdy aplikacja urośnie z 100 do 10 000 użytkowników?

Architektura DV zaprojektowana pod scaling, ale bottlenecki pojawiają się przy konkretnych progach:

100-1 000 użytkowników: zero zmian w infrastrukturze, 1 VPS (4-8 GB RAM, 2-4 vCPU) wystarczy. Koszt 100-300 zł/mies.

1 000-10 000 użytkowników: opcjonalna replika read-only PostgreSQL dla raportów (offload primary), Redis cache dla hot queries, CDN dla static assets. Migracja 1-2 sprinty. Koszt infrastruktury 500-1 500 zł/mies.

10 000-100 000 użytkowników: horizontal scaling (load balancer + 2-4 app servers), read replicas PostgreSQL, queue processing (BullMQ + Redis), edge caching (Cloudflare). Architektura nie wymaga przepisywania — modułowa struktura od dnia 1 pozwala na skalowanie elementów osobno. Koszt 2 000-8 000 zł/mies.

100 000+ użytkowników: decyzja per case — zwykle wymaga re-architecturing kluczowych modułów (sharding, microservices gdzie ma sens, dedicated infrastructure team). DV pomaga w decyzjach, ale realnie 100k+ aplikacja to zwykle inna firma operatorska niż 10k.

Database (PostgreSQL) skaluje się do 1M+ użytkowników bez re-architecturing, jeśli queries są dobrze zindeksowane i wzorce dostępu przewidywalne.

03VENDOR LOCK-IN
Czy stack DV (Next.js + Payload) tworzy vendor lock-in?

Krótka odpowiedź: nie, stack jest open-source, kod Twój.

Długa odpowiedź — co konkretnie chroni przed lock-in:

Frameworki open-source:

Next.js (MIT license) — used by Netflix, TikTok, Twitch — zero ryzyka „maintainer porzucił"
Payload CMS (MIT license) — własność platformy do CMS, możesz hostować gdzie chcesz
PostgreSQL (PostgreSQL License) — najczęściej używana relacyjna baza danych w produkcji, deweloper PostgreSQL znajdziesz wszędzie

Brak proprietary DV libraries:

Każda zależność w package.json ma publiczny npm registry
Zero „DV Framework" lub „DV Auth Library" których nie ma na npm
Konfiguracja deployment w git repo, nie w „DV Cloud Console"

Code w Twoim repo:

GitHub/GitLab Twoja licencja
Pełna git history dostępna
Zmiana dewelopera/agencji = pull request, nie „odzyskiwanie kodu z chmury DV"

Realne case z naszej praktyki: 2 klientów po 18-24 miesiącach przeszło na in-house team. Senior developer odnalazł się w kodzie w 1-2 tygodnie (Next.js + PostgreSQL = standard rynkowy).

Jedyne "lock-in" to wybór architektoniczny — jeśli aplikacja zbudowana na Next.js, migracja do Vue/Angular wymaga przepisania frontend. To nie unique do DV — każda agencja taki "lock-in" tworzy. DV vs konkurencja: my wybieramy frameworki z 5+ lat track record, nie hype-driven (Stable stack — Blok 7 hubu /tworzenie-oprogramowania).

04COMPLIANCE
Czy DV buduje aplikacje pod RODO Art. 9 (medycyna), KNF (finanse) lub SOC2?

RODO Art. 9 (dane wrażliwe — medycyna, dane biometryczne): Tak. Baseline DV (encrypted at rest, audit log, RBAC, multi-factor auth) pokrywa core wymogi. Discovery (Etap 02) zawiera RODO gap analysis — co dodatkowo aplikacja potrzebuje (np. specific retention policies, consent management, DPIA support). Realnie 4-6 projektów RODO Art. 9 zrealizowanych, głównie medycyna i HR.

KNF (sektor finansowy): Częściowo. Baseline aplikacji webowej DV pokrywa security i audit, ale specific KNF compliance (rekomendacje D, M, Z) wymaga często external compliance consultanta. DV pracuje w trybie collaboration — my budujemy aplikację, klient + KNF compliance firma walidują. 1-2 projekty fintech zrealizowane (nie pełny banking, ale adjacent — fintech B2B, lending platform).

SOC2 / ISO 27001: Nie default. Te audyty wymagają operacyjnych procesów firmy (ciągłe monitoring, incident response procedures, employee training, physical security data center) — nie tylko aplikacja webowa. DV buduje aplikację z technicznymi kontrolami SOC2-ready (audit log, encryption, access control), ale certyfikacja jest po stronie klienta lub external SOC2 audit firmy.

HIPAA / GDPR US compliance: Nie. DV pracuje na rynkach Polska / EU / Szwajcaria. Dla US healthcare compliance polecamy specjalistyczne firmy.

05MIGRACJA Z LEGACY
Czy DV migruje istniejące aplikacje (PHP legacy, stary .NET, custom enterprise)?

Tak, ale selektywnie. Migracja legacy to często 60-80% budżetu nowej aplikacji, a output ma sens tylko jeśli istniejący system rzeczywiście blokuje biznes.

Trzy scenariusze migracji które robimy:

1. Migracja UI/frontend, backend zostaje: Najczęstszy case. Stary monolit PHP/Java/.NET zostaje, dodajemy nowy frontend Next.js komunikujący się z istniejącym backend przez API. Czas: 8-12 tygodni. Ryzyko: niskie. ROI: szybki (klient widzi nowoczesny interface w 2-3 miesiące).

2. Migracja stopniowa (strangler pattern): Stary system zostaje w produkcji, nowe moduły w Next.js + Payload zastępują legacy moduły jeden po drugim. Czas: 12-24 miesiące. Ryzyko: średnie. ROI: rozłożony, mniejszy disruption biznesowy.

3. Pełna migracja (rebuild): Stary system zarchiwizowany (read-only), nowy system zastępuje 100% funkcjonalności. Czas: 16-32 tygodnie. Ryzyko: wysokie (data migration, user training, rollback strategy). ROI: długoterminowy, ale wymaga business case ROI 3-5 lat.

Czego NIE robimy:

Migracja stack'u którego DV nie używa w produkcji (Java legacy, Ruby on Rails legacy, custom mainframe)
„Małe poprawki" w istniejącym legacy code'ie (freelancer scope)
Rebuild bez clear business case (custom dla custom = fail)

06MOBILE
Czy do aplikacji webowej można później dodać aplikację mobilną?

Tak — i często to robimy. Aplikacja webowa DV zaprojektowana API-first (Next.js API Routes lub dedykowany backend). Mobile app może wykorzystać ten sam backend bez przepisywania logiki biznesowej.

Stack mobile: React Native (Expo) — code reuse 60-80% z aplikacji webowej React/Next.js. Shared:

Business logic (TypeScript)
API client
Validation schemas (Zod)
Type definitions

Co specific dla mobile:

UI components (mobile patterns, gesture handling)
Push notifications (FCM/APNs)
Offline mode (jeśli wymagane)
App Store / Play Store deployment

Typowy harmonogram dodania mobile:

6-10 tygodni dla companion app (czyta/edytuje te same dane co web app)
12-16 tygodni dla feature-rich mobile (offline, push, hardware integration)
Cena: od 40 000 zł (companion) do 150 000+ zł (full custom)

Native (Swift/Kotlin): Tylko gdy konkretne wymagania (zaawansowana grafika, performance- critical features, hardware integration jak BLE/NFC). W praktyce DV robi React Native w 80%+ projektów mobile. Dla native wykonawców polecamy specialized mobile shops.

07DEPLOYMENT
Czy aplikacja musi być na serwerach DV, czy mogę hostować u siebie?

Możesz hostować gdzie chcesz. DV nie wymaga deployment na własnej infrastrukturze.

Trzy modele deployment:

1. DV-managed VPS (najczęstszy, 70% projektów): DV stawia VPS na Twoje konto, konfiguruje, monitoring, backupy. Ty płacisz za VPS bezpośrednio (80-200 zł/mies.), DV za opiekę techniczną osobno (450-1500 zł/mies.). Dostęp root masz Ty.

2. Klient-managed (twoja infrastruktura): Twój zespół IT zarządza infrastrukturą — własny VPS, on-premises serwer, klastrowy Kubernetes. DV przekazuje:

Docker images aplikacji
Deployment runbook (krok-po-kroku jak deployować)
Database migration scripts
Configuration template (env vars, secrets)
1-2 sesje knowledge transfer dla Twojego zespołu

Najczęściej dla klientów enterprise lub firm z dedicated DevOps team.

3. Cloud (AWS / GCP / Azure): Jeśli klient ma już ekosystem chmurowy. DV deploy'uje aplikację na Twoim koncie cloud, konfiguracja IaC (Terraform/ Pulumi) w git repo, Ty kontrolujesz billing i access.

Kluczowe:

Kod w Twoim git repo — niezależnie od deployment model
Database backupy w Twoim cloud storage — zero retention na infrastrukturze DV
Sekrety (API keys, passwords) w Twoich secrets manager — DV nie przechowuje credentials klientów long-term
Migration path — przejście z DV-managed → klient-managed zawsze możliwe (export Docker images + database dump + konfiguracja)

↳ To 7 pytań specific dla aplikacji webowych. Pytania ogólne o software (build/buy, code ownership, decyzje architektoniczne, harmonogram) — w /nasza-oferta/tworzenie-oprogramowania Blok FAQ. Pytania ogólne o współpracę z DV — w /nasza-oferta Blok FAQ.

KIEDY WARTO · 4 SYGNAŁY

Kiedy aplikacja webowa zwraca się szybciej niż gotowy SaaS

01WORKFLOW NIE PASUJE

Wdrożony SaaS wymusza zmianę procesu zamiast wspierać

Konkretne objawy:

Custom workflow wymaga 5+ workaround-ów w gotowym narzędziu
30%+ funkcji nieużywane bo nie pasują do branży/procesu
Pracownicy mówią „prościej zrobić to w Excelu"
Subskrypcje narzędzi do automatyzacji rosną, bo gotowy SaaS nie ma kluczowych integracji

Custom aplikacja: workflow w 100% pod proces firmy, jedna baza danych, jeden login, jedna logika.

02DATA SILOS

Dane między systemami przepływają przez ludzi, nie API

Zamówienie z marketplace kopiowane manualnie do księgowości. Lead z formularza www przepisywany do CRM. Faktura wprowadzana ponownie do raportu zarządczego. Każda operacja to 5-15 minut

ryzyko błędu.

Konkretne objawy:

3+ systemy w firmie, dane przepływają przez Excela/email/PDF
Pracownik backoffice spędza >20% czasu na manualnym kopiowaniu danych
Raporty zarządcze są spóźnione bo dane trzeba „ściągnąć"
Każdy nowy klient = setup w 4-5 systemach osobno

Custom aplikacja z API integration: synchronizacja w czasie rzeczywistym, single source of truth, raporty zarządcze automatyczne.

03SAMOOBSŁUGA 24/7

Klient B2B oczekuje samoobsługi, my obsługujemy mailowo

Konkretne objawy:

Klient pyta „czy macie panel klienta?"
30%+ czasu zespołu obsługi to powtarzalne pytania o status
Zwroty/reklamacje generują 5+ maili tam i z powrotem
Konkurenci w branży mają portal klienta, wy nie

Custom panel klienta: redukcja obsługi powtarzalnej o 50-70%, sygnał profesjonalizmu rynkowego.

04DECYZJE NA DANYCH

Decyzje zarządcze na podstawie spóźnionych raportów Excel

Konkretne objawy:

Raporty zarządcze przygotowywane manualnie, 1-3 dni pracy per raport
Zarząd pyta „jak nam idzie?" — odpowiedź wymaga 4 maili do różnych działów
Dane z 3+ systemów łączone w Excel za każdym razem od nowa
Pracownik analityki przeładowany pracą, której większość jest powtarzalna

Custom dashboard: real-time data z agregacją, self-service drill-down, alerty na anomalie.

5 SCENARIUSZY · WYBIERZ TYP APLIKACJI

Co konkretnie budujemy

01SAAS

SaaS multi-tenant — od MVP do produktu

Multi-tenant · Subskrypcje · Auth · Białe-label · Scaling-ready

Stack: Next.js + Payload + PostgreSQL + Stripe. Architektura modułowa pod 3-5 lat rozbudowy iteracyjnej.

Typowy projekt: 8-16 tygodni. Cena: od 50 000 zł.

02DASHBOARD

Dashboard zarządczy z real-time data

BI · Agregacja danych · Self-service drill-down · Alerty

Typowy projekt: 6-12 tygodni. Cena: od 30 000 zł.

03DASHBOARD

Dashboard zarządczy z real-time data

BI · Agregacja danych · Self-service drill-down · Alerty

Typowy projekt: 6-12 tygodni. Cena: od 30 000 zł.

04CUSTOM CRM

Custom CRM dla branż, których nie obsługuje gotowy SaaS

Workflow · Pipeline · Integracje · Branża-specific

Typowy projekt: 8-14 tygodni. Cena: od 40 000 zł.

Dedykowana sub-strona w przygotowaniu — pełny opis i kalkulator dostępne wkrótce.

05B2B PORTAL

B2B portal partnerski dla firm 100-300 osób

Partnerzy · Distributors · Agenci · White-label · Multi-region

Typowy projekt: 12-20 tygodni. Cena: od 80 000 zł.

Dedykowana sub-strona w przygotowaniu — pełny opis i kalkulator dostępne wkrótce.

CO DOSTAJESZ · 4 KONKRETY APP-SPECIFIC

Co dostajesz w cenie aplikacji webowej DV

Cztery rzeczy w standardzie każdej aplikacji webowej DV — niezależnie czy to SaaS, portal klienta, dashboard czy custom CRM. Nie upselle, nie pakiety premium — baseline dla każdego projektu.

UX ZAPROJEKTOWANE POD BIZNES

UX dopasowane do realnego workflow, nie do design trendów

DV pracuje inaczej:

User research z 3-5 przyszłymi użytkownikami przed rozpoczęciem designu (Etap 02 procesu) — co realnie robią, jak długo, jak często
Wireframes testowane z użytkownikami przed kodem (klikalny prototyp Figma)
Design tokens jako CSS variables — spójność visualu, ale workflow-first
A/B testy najważniejszych flow po launch'u — iteracja na danych, nie zgadywanie

Konsekwencja: pracownicy adoptują aplikację w 1-2 tygodnie, a nie „uczymy się tego od 3 miesięcy".

MONITORING I ALERTY DLA WŁAŚCICIELA

Wiesz wcześniej niż użytkownik gdy coś nie działa

Standard DV w każdej aplikacji webowej:

Sentry — error tracking z full stack trace + session replay (widzimy co user robił przed błędem)
Uptime monitoring co 5 minut — alerty SMS/email gdy aplikacja niedostępna >2 min
PostHog — product analytics + heatmapy + session recordings
Application Performance Monitoring (czas response, queries DB, bottlenecki)
Centralized logging z retention 30 dni + alerty na anomalie

Konsekwencja: błąd produkcyjny zgłaszamy My do Was. Fix typowo w 2-4h od incydentu. Twój zespół nie traci czasu na „ktoś mówi że nie działa, sprawdzimy".

ARCHITEKTURA POD 3-5 LAT ROZBUDOWY

Aplikacja, do której dodaje się funkcje, a nie przepisuje

Aplikacje webowe żyją 3-5 lat. Architektura zaprojektowana pod tę perspektywę, nie pod „byle launch w 8 tygodni":

Monorepo structure (apps/web, apps/admin, packages/database, packages/ui) — dodanie panelu admin lub mobile app bez przepisywania
TypeScript strict mode + Zod validation — kontrakty między modułami sprawdzane compile-time (błędy łapane przed deployment)
Database migrations w wersjonowanym kodzie — schema evolution bez "ALTER TABLE w produkcji"
Multi-tenancy ready (nawet single-tenant aplikacje) — dodanie drugiego klienta to konfiguracja, nie refactor
Feature flags + A/B testing infrastructure od pierwszego dnia

Konsekwencja: rozbudowa za 2 lata to dodanie funkcji w 2-4 sprintach, nie 6-miesięczny refactor całego systemu.

AUTH I SECURITY W STANDARDZIE

Bezpieczeństwo niewidoczne dla użytkownika, ale obecne

Aplikacja webowa to dane klientów Twojej firmy — naruszenie oznacza realny problem prawny (RODO), reputacyjny i operacyjny. Security baseline w standardzie:

Authentication: NextAuth/Auth.js lub Clerk (multi-factor 2FA, passwordless, SSO opcjonalnie)
Authorization: role-based access control (RBAC) z poziomu kodu i bazy danych (defense in depth)
Encrypted at rest (PostgreSQL TDE) + encrypted in transit (TLS 1.3)
OWASP Top 10 covered: SQL injection, XSS, CSRF, broken auth, security misconfiguration
Rate limiting na API endpoints (zabezpieczenie przed brute-force i DDoS)
Audit log w bazie: kto, kiedy, co zmienił (RODO compliance)

Konsekwencja: aplikacja przechodzi audit security klienta enterprise bez panicznego refactoru. Compliance team klienta dostaje dokumentację (security checklist) w handoff.

STACK · 4 WARSTWY ARCHITEKTURY

Stack technologiczny dla aplikacji webowych

01FRONTEND

Next.js + React Server Components + Tailwind

Default frontend dla aplikacji webowych moze być: Next.js z App Router i React Server Components. Tailwind CSS + shadcn/ui jako component library. React Hook Form + Zod do walidacji formularzy.

Dlaczego ten stack:

Next.js App Router — server components redukują JavaScript bundle 30-60% vs pure client React, lepszy LCP/TTI
Tailwind + shadcn/ui — design tokens jako CSS variables, component library copy-paste (nie node_modules dependency)
Zod walidacja — single source of truth dla types frontend + backend + database

Kiedy odstąpienie:

Vue / Nuxt — gdy klient ma już Vue ekosystem w firmie
Astro — dla aplikacji content-heavy z minimal interaktywności (dokumentacja, portal informacyjny)
Angular — enterprise klienci z istniejącą bazą Angular

W 90% projektów aplikacji webowych DV: Next.js. Pozostałe 10% zależy od klienta.

02BACKEND I DATABASE

Node.js + TypeScript + PostgreSQL + Prisma

Redis (gdy potrzeba) lub Inngest (serverless background tasks).

Dlaczego PostgreSQL:

ACID transactions — zero ryzyka utraty danych
JSONB columns — flexibility NoSQL, ale w relacyjnej bazie
Row-level security — multi-tenancy ready bez application-layer hacks
Production proven — od 1996 roku, używany przez Stripe, Reddit, Instagram

Dlaczego Prisma:

Type-safe queries — błąd w queryach łapany compile-time
Auto-generated migrations z schema diff
Studio (GUI dla bazy) w developerce, prod-safe w produkcji

Alternatywy considered: Drizzle (lżejszy ORM, edge-deployment), TypeORM (legacy projekty), raw SQL (gdy Prisma constraint).

03AUTH I MULTI-TENANCY

Auth dobierany pod model biznesowy aplikacji

Auth nie ma jednego "default'a" w aplikacjach webowych — zależy od modelu biznesowego:

Single-tenant (jedna firma, wielu pracowników):

NextAuth/Auth.js + email magic links lub OAuth (Google, Microsoft) — najprostsze, zero vendor lock-in
Role-based access control z bazy (RBAC) — admin/user/viewer

Multi-tenant SaaS (wielu klientów, każdy z własnym workspace):

Clerk lub WorkOS — gotowe rozwiązania z multi-org support, SSO, SCIM provisioning
Custom rozwiązanie na NextAuth (gdy budget tight lub specific wymogi)

B2B portal z partnerami:

SSO (Single Sign-On) z systemu klienta — SAML 2.0 lub OAuth
Provisioning automatyczny z HR systemu klienta

Auth security baseline (każda aplikacja):

Multi-factor 2FA opcjonalne dla użytkownika
Rate limiting na login endpoints (brute-force protection)
Audit log każdego logowania (RODO compliance)
Sesje z secure HttpOnly cookies

04 INFRASTRUKTURA I DEPLOYMENT

Infrastruktura dobierana pod skalę i wymogi

Najczęstsze scenariusze deployment aplikacji webowych DV:

VPS — 80% projektów polskich klientów:

VPS — koszt 80-200 zł/mies.
Docker containers, Traefik load balancer, automated SSL
Database PostgreSQL na tym samym VPS lub osobny (zależnie od skali)
Backup codziennie + retention 30 dni

Cloud (AWS / GCP / Azure) — 15% projektów:

Gdy klient ma już ekosystem chmurowy (Azure AD, AWS S3, GCP BigQuery)
Architektura serverless (Lambda/Cloud Functions) dla event-driven workflows
Managed database (RDS/CloudSQL) — wyższy koszt, ale zarządzane przez cloud provider

Vercel + Neon/Supabase — 5% projektów:

Globalny edge network — gdy aplikacja ma użytkowników na 3+ kontynentach
Zero DevOps overhead — automated preview deployments per PR
Trade-off: koszt rośnie nieliniowo przy skali (>200k MAU)

CI/CD każda aplikacja:

GitHub Actions — automated tests + build + deploy do staging po każdym merge
Production release manualne po code review + acceptance testing

PROCES · 5 ETAPÓW · 8-16 TYGODNI5 etapów

Od konsultacji do produkcji — etapami

1-2 tygodnie · bezpłatnie

KONSULTACJA ARCHITEKTONICZNA

Output: ADR (Architectural Decision Record) v0 + decyzja stack'u (frontend / backend / database / auth / infrastructure) z 2-3 alternatywami per warstwa. Każda decyzja ma uzasadnienie biznesowe.

2-3 tygodnie · płatny deliverable

DISCOVERY I SPECYFIKACJA

Output: 4 dokumenty heritage tabular:

ERD (Entity Relationship Diagram) — schema bazy danych
API contract (OpenAPI 3.0 spec)
Integration map — które systemy zewnętrzne, jakie operacje
User stories + acceptance criteria — testowalne wymagania

Dla SaaS multi-tenant dodatkowo: tenant isolation strategy (row-level security vs schema-per-tenant vs database-per-tenant).

2-4 tygodnie

UX/UI + PROTOTYP TESTOWANY

Dla aplikacji z istniejącym design system klienta (po brandingu DV lub innym dostawcy) — adaptujemy do istniejących wytycznych zamiast tworzyć od zera.

4-12 tygodni · sprinty 2-tygodniowe

DEVELOPMENT + STAGING OD DNIA 1

MVP scope: core user journey + critical integrations. Funkcje secondary (raporty advanced, edge case handling, admin panel deluxe) — po MVP launch'u na podstawie realnych user feedback.

Każdy PR = preview deployment z unique URL — klient testuje zmiany izolowane od main staging.

Launch + 30 dni stabilizacji

LAUNCH + MONITORING + STABILIZACJA

Po stabilizacji 3 opcje:

Koniec współpracy — zero lock-in, kod Twój
Opieka techniczna abonament
Rozbudowa kolejnych funkcji

Handoff dokumentacja heritage tabular:

README + setup instructions (local dev w 30 min)
ADR (Architectural Decision Records) — dlaczego ten stack
Deployment runbook (jak deployować, jak rollback, jak debug produkcji)
Database schema docs + migrations history
Integration runbooks (jak skonfigurować Stripe webhooks, jak rotate API keys, jak debug failed sync)
Monitoring playbook — jakie alerty znaczą co, kiedy wakeup-on-call (jeśli aplikacja krytyczna)

HARMONOGRAM PROJEKTU APLIKACJI WEBOWEJ

8-16 tygodni

ŁĄCZNIE

8-12 tygodni

PORTAL KLIENTA / DASHBOARD

12-20+ tygodni

SAAS MULTI-TENANT

↳ Konkretny harmonogram po Discovery (Etap 02). Projekty SaaS enterprise (multi-region, compliance audit, dedicated support) — 20+ tygodnie. Konsultujemy indywidualnie.

CENNIK · 3 TIER'Y APLIKACJI WEBOWEJ

Ile kosztuje aplikacja webowa

Każdy projekt wycenianego indywidualnie po Discovery. Poniżej 3 tier'y skali typowej dla aplikacji webowych DV + kalkulator do oszacowania własnego projektu w 4 minuty.

01MAŁA

30 - 60 tys. zł

Czas: 6-8 tygodni

Pojedynczy moduł, 1-2 role użytkowników

1-2 role użytkowników (np. admin + user)
5-15 ekranów core
1-2 integracje API (np. Stripe + email)
Single-tenant architecture
Auth standard (NextAuth/Clerk)
Monitoring stack (Sentry + Uptime + PostHog)

02ŚREDNIA

60 - 120 tys. zł

Czas: 8-12 tygodni

3-5 ról, integracje, prosty multi-tenant

3-5 ról użytkowników z RBAC
15-40 ekranów core
3-5 integracji API (CRM + księgowość + płatności + email + analytics)
Multi-tenant ready (single-tenant deploy, ale architektura pod skalowanie)
Auth z multi-factor + audit log
Background jobs (queue processing, scheduled tasks, email sending)
Pełny monitoring + alerts

03ZŁOŻONA

120 - 300+ tys. zł

Czas: 12-20+ tygodni

Multi-tenant SaaS, compliance, advanced features

Multi-tenant SaaS architecture (row-level security lub schema-per-tenant)
5+ ról użytkowników z complex RBAC + custom permissions
40+ ekranów core
5-15 integracji API + webhooks bidirectional
Advanced features: białe-label, custom fields per tenant, workflow engine, reporting builder
Compliance ready (RODO Art. 9, KNF, audit trail)
Real-time collaboration (WebSocket/SSE)
Subskrypcje (Stripe billing) + usage-based pricing

Co najmocniej decyduje o cenie aplikacji webowej

Honest scope:

Hosting i infrastruktura w produkcji (VPS 80-200 zł/mies., cloud per usage, dedicated od 500 zł/mies.)
Monitoring tools — Sentry, PostHog, Uptime monitoring (Free dla małej skali, dalej od ~$25/mies. per tool)
External services płatne per użycie (Stripe 1.4-2.9% per transaction, Twilio per SMS, OpenAI per token, email delivery od 50 zł/mies.)
Domeny + SSL (~100 zł/rok)
Marketing kampanii (App Store Optimization, ads, content)
Treści (copywriting, grafika produktowa) — możemy wskazać sprawdzonych dostawców

Long-term koszty: zwykle 8-15% rocznie wartości projektu na hosting + opieka techniczna + drobne rozbudowy.

Czego nie obejmują nasze widełki

Heritage scope — co poza naszym obszarem pracy:

Lean MVP za 10-20 tys. zł — przy tym budżecie powstaje zwykle throwaway code. Lepsze opcje: no-code (Bubble, FlutterFlow) jako pierwszej walidacji, freelancer senior z portfolio, akcelerator startupowy z built-in tech support.
Custom enterprise z budżetami 1mil. zł — multi-region failover, custom hardware, dedicated support team 24/7 — pasują większe firmy konsultingowe (100+ osób software house).
Migracja legacy enterprise systems (mainframe, JEE legacy, custom ERP-y stare 15+ lat) — DV nie pracuje z legacy stack'iem.
Pojedyncze poprawki w istniejącej aplikacji innej agencji — pracujemy projektowo (Discovery → Wdrożenie → Long-term opieka), nie godzinowo na drobnice.

Jeśli Twój projekt mieści się w powyższych kategoriach — mówimy to wprost zamiast brać projekt którego nie zrobimy optymalnie.

Co NIE jest w cenie projektu

Honest scope:

Hosting i infrastruktura w produkcji (VPS 80-200 zł/mies., cloud per usage, dedicated od 500 zł/mies.)
Monitoring tools — Sentry, PostHog, Uptime monitoring (Free dla małej skali, dalej od ~$25/mies. per tool)
External services płatne per użycie (Stripe 1.4-2.9% per transaction, Twilio per SMS, OpenAI per token, email delivery od 50 zł/mies.)
Domeny + SSL (~100 zł/rok)
Marketing kampanii (App Store Optimization, ads, content)
Treści (copywriting, grafika produktowa) — możemy wskazać sprawdzonych dostawców

Long-term koszty: zwykle 8-15% rocznie wartości projektu na hosting + opieka techniczna + drobne rozbudowy.

Policz koszt aplikacji webowej Opisz swój projekt

CO ODRÓŻNIA NAS · 3 RZECZY APP-SPECIFIC

3 rzeczy, które robimy inaczej w aplikacjach webowych

MULTI-TENANCY READY

Architektura multi-tenant nawet dla single-tenant projektów

DV pracuje inaczej. Każda aplikacja webowa zaprojektowana multi-tenant ready od pierwszego sprintu, nawet jeśli deploy jest single-tenant:

Database schema z tenant_id w każdej tabeli (nawet dla single-tenant — tenant_id = '1')
Row-level security (RLS) w PostgreSQL — izolacja danych na poziomie bazy, nie aplikacji
Tenant routing (subdomain lub path-based) — gotowy do aktywacji w 1-2 sprintach
Per-tenant config (logo, primary color, feature flags, pricing plans) — schema gotowa, UI panel dodawany on-demand
Middleware auth z tenant context — request zawsze zna swojego tenant'a

PRODUCTION-READY

Staging od sprintu 1, monitoring przed launchem, zero „big bang"

DV pracuje inaczej:

Staging environment od sprintu 1 — link aktualny zawsze, klient testuje feature N+1 podczas pracy nad N+2
Continuous deployment — każdy merge do main = auto-deploy do staging w 5-10 min
Preview deployments per PR — każdy pull request = unique URL z izolowanym deployment
Code quality w CI/CD — TypeScript strict, ESLint, Vitest unit testy, Playwright E2E dla critical paths. Merge blocked jeśli nie przechodzi standards
Monitoring stack konfigurowany przed launch'em — Sentry, Uptime, PostHog, APM, centralized logging. Nie "dodamy po launch'u", tylko "działa przed pierwszym userem"

CODE OWNERSHIP

Kod w Twoim repo od pierwszego sprintu, zero proprietary DV libraries

DV pracuje inaczej od pierwszego sprintu:

Pełny kod źródłowy w Twoim GitHub/GitLab — od pierwszego commit, nie po launch, nie po ostatniej fakturze
Twoja licencja, Twoja własność intelektualna — zero klauzul „DV zachowuje prawa do kodu" w umowie
Open-source / standard frameworks tylko — Next.js, Payload, PostgreSQL, Stripe — zero proprietary DV libraries których nie ma na npm
Zero hidden integrations — każda zewnętrzna integracja ma audit trail w kodzie + dokumentację jak ją skonfigurować pod własnym kontem klienta
Handoff dokumentacja w cenie — README + ADR + deployment runbook + database schema docs + integration runbooks (6 dokumentów heritage tabular)

DLA KOGO DV · I DLA KOGO NIE

Dla kogo budujemy aplikacje webowe — i dla kogo nie

Firma 30-150 osób, custom system jako must-have

Typowe branże: usługi profesjonalne (prawne, medyczne, finansowe), B2B SaaS dla niszowych rynków, e-commerce z custom workflow, producenci z eksportem, firmy usługowe z sieciami lokalizacji.

Co Ci dajemy: dedykowaną aplikację pod Twój workflow, multi-tenant ready architecture od dnia 1, monitoring i opieka techniczna long-term (450-1500 zł/mies.).

Gotowy SaaS pokrywa 70%+ Twoich potrzeb

Custom aplikacja webowa to inwestycja długoterminowa (50-300k zł + 5-15% rocznie utrzymania). Jeśli gotowy SaaS pokrywa większość potrzeb — kup, nie buduj.

Najczęstsze sytuacje gdy mówimy „kup gotowy SaaS":

CRM dla 10-30 osób — Pipedrive, HubSpot Free, Bitrix24 starter
Project management — gotowy project management SaaS, branżowy SaaS (np. dla architektów, prawników)
Mailing automation — Brevo, Mailchimp, ActiveCampaign
Bookingi/rezerwacje — Calendly, Cal.com, branżowy SaaS
Helpdesk/ticketing — gotowe rozwiązania od ~200 zł/mies.

W 20-minutowej konsultacji architektonicznej DV przeprowadzi Cię przez build/buy decision. 15-20% rozmów kończy się rekomendacją „nie buduj, kup gotowy SaaS X".

Startup post-MVP, refactor lub rebuild pod scale

Co dostajecie u DV: production-ready stack od pierwszego dnia, multi-tenant architecture, monitoring + alerts, due-diligence documentation w handoff.

Lean MVP za 10-20 tys. zł / proof-of-concept w tydzień

Polecane alternatywy:

No-code platformy — Bubble (najsilniejszy dla web apps), FlutterFlow (mobile + web), Glide (proste internal tools)
Freelancer senior z portfolio podobnych projektów (Useme, Bulldogjob, polskie społeczności tech)
Akcelerator startupowy z built-in tech support (PARP Platformy startowe, Startup Booster Poland — dofinansowanie)

Wracaj do nas gdy MVP zwaliduje hipotezę biznesową i potrzebujesz production-ready system pod scale (100+ użytkowników, multi-tenant, SLA, compliance).

Firma 100-300 osób, outsourcing modułu większego systemu

Enterprise 500+ pracowników, budżet 1+ mil. zł, multi-region

Pasują większe firmy konsultingowe (100+ osób software house polskie/międzynarodowe) lub direct hire enterprise dev team.

FAQ · 7 PYTAŃ O APLIKACJE WEBOWE

Pytania, które dostajemy w fazie konsultacji

01MULTI-TENANCY
Kiedy aplikacja powinna być multi-tenant, a kiedy single-tenant wystarczy?

Trzy kryteria decyzyjne:

Czy aplikacja będzie obsługiwać >1 klienta/zespół/markę w przyszłości 3-5 lat?

Tak (nawet hipotetycznie) → multi-tenant ready od dnia 1
Nie pewne → multi-tenant ready architecture, ale single-tenant deploy (DV default)
Definitywnie nie → single-tenant (rzadkie w praktyce)

Czy aplikacja ma kiedyś być białe-label dla resellerów?

Tak → multi-tenant required, custom branding per tenant
Nie → single-tenant ok

Compliance wymóg izolacji danych między klientami?

Tak (medycyna RODO Art. 9, finanse KNF) → schema-per-tenant lub database-per-tenant
Standard biznes → row-level security w PostgreSQL wystarcza

02SCALING I PERFORMANCE
Co się stanie gdy aplikacja urośnie z 100 do 10 000 użytkowników?

Architektura DV zaprojektowana pod scaling, ale bottlenecki pojawiają się przy konkretnych progach:

100-1 000 użytkowników: zero zmian w infrastrukturze, 1 VPS (4-8 GB RAM, 2-4 vCPU) wystarczy. Koszt 100-300 zł/mies.

Database (PostgreSQL) skaluje się do 1M+ użytkowników bez re-architecturing, jeśli queries są dobrze zindeksowane i wzorce dostępu przewidywalne.

03VENDOR LOCK-IN
Czy stack DV (Next.js + Payload) tworzy vendor lock-in?

Krótka odpowiedź: nie, stack jest open-source, kod Twój.

Długa odpowiedź — co konkretnie chroni przed lock-in:

Frameworki open-source:

Next.js (MIT license) — used by Netflix, TikTok, Twitch — zero ryzyka „maintainer porzucił"
Payload CMS (MIT license) — własność platformy do CMS, możesz hostować gdzie chcesz
PostgreSQL (PostgreSQL License) — najczęściej używana relacyjna baza danych w produkcji, deweloper PostgreSQL znajdziesz wszędzie

Brak proprietary DV libraries:

Każda zależność w package.json ma publiczny npm registry
Zero „DV Framework" lub „DV Auth Library" których nie ma na npm
Konfiguracja deployment w git repo, nie w „DV Cloud Console"

Code w Twoim repo:

GitHub/GitLab Twoja licencja
Pełna git history dostępna
Zmiana dewelopera/agencji = pull request, nie „odzyskiwanie kodu z chmury DV"

Realne case z naszej praktyki: 2 klientów po 18-24 miesiącach przeszło na in-house team. Senior developer odnalazł się w kodzie w 1-2 tygodnie (Next.js + PostgreSQL = standard rynkowy).

04COMPLIANCE
Czy DV buduje aplikacje pod RODO Art. 9 (medycyna), KNF (finanse) lub SOC2?

HIPAA / GDPR US compliance: Nie. DV pracuje na rynkach Polska / EU / Szwajcaria. Dla US healthcare compliance polecamy specjalistyczne firmy.

05MIGRACJA Z LEGACY
Czy DV migruje istniejące aplikacje (PHP legacy, stary .NET, custom enterprise)?

Tak, ale selektywnie. Migracja legacy to często 60-80% budżetu nowej aplikacji, a output ma sens tylko jeśli istniejący system rzeczywiście blokuje biznes.

Trzy scenariusze migracji które robimy:

Czego NIE robimy:

Migracja stack'u którego DV nie używa w produkcji (Java legacy, Ruby on Rails legacy, custom mainframe)
„Małe poprawki" w istniejącym legacy code'ie (freelancer scope)
Rebuild bez clear business case (custom dla custom = fail)

06MOBILE
Czy do aplikacji webowej można później dodać aplikację mobilną?

Stack mobile: React Native (Expo) — code reuse 60-80% z aplikacji webowej React/Next.js. Shared:

Business logic (TypeScript)
API client
Validation schemas (Zod)
Type definitions

Co specific dla mobile:

UI components (mobile patterns, gesture handling)
Push notifications (FCM/APNs)
Offline mode (jeśli wymagane)
App Store / Play Store deployment

Typowy harmonogram dodania mobile:

6-10 tygodni dla companion app (czyta/edytuje te same dane co web app)
12-16 tygodni dla feature-rich mobile (offline, push, hardware integration)
Cena: od 40 000 zł (companion) do 150 000+ zł (full custom)

07DEPLOYMENT
Czy aplikacja musi być na serwerach DV, czy mogę hostować u siebie?

Możesz hostować gdzie chcesz. DV nie wymaga deployment na własnej infrastrukturze.

Trzy modele deployment:

2. Klient-managed (twoja infrastruktura): Twój zespół IT zarządza infrastrukturą — własny VPS, on-premises serwer, klastrowy Kubernetes. DV przekazuje:

Docker images aplikacji
Deployment runbook (krok-po-kroku jak deployować)
Database migration scripts
Configuration template (env vars, secrets)
1-2 sesje knowledge transfer dla Twojego zespołu

Najczęściej dla klientów enterprise lub firm z dedicated DevOps team.

Kluczowe:

Kod w Twoim git repo — niezależnie od deployment model
Database backupy w Twoim cloud storage — zero retention na infrastrukturze DV
Sekrety (API keys, passwords) w Twoich secrets manager — DV nie przechowuje credentials klientów long-term
Migration path — przejście z DV-managed → klient-managed zawsze możliwe (export Docker images + database dump + konfiguracja)

Aplikacja webowa dla firmy, która wyrosła z arkuszy

Aplikacja webowa dla firmy, która wyrosła z arkuszy

Kiedy aplikacja webowa zwraca się szybciej niż gotowy SaaS

Wdrożony SaaS wymusza zmianę procesu zamiast wspierać

Dane między systemami przepływają przez ludzi, nie API

Klient B2B oczekuje samoobsługi, my obsługujemy mailowo

Decyzje zarządcze na podstawie spóźnionych raportów Excel

Co konkretnie budujemy

SaaS multi-tenant — od MVP do produktu

Multi-tenant · Subskrypcje · Auth · Białe-label · Scaling-ready

Dashboard zarządczy z real-time data

BI · Agregacja danych · Self-service drill-down · Alerty

Dashboard zarządczy z real-time data

BI · Agregacja danych · Self-service drill-down · Alerty

Custom CRM dla branż, których nie obsługuje gotowy SaaS

Workflow · Pipeline · Integracje · Branża-specific

B2B portal partnerski dla firm 100-300 osób

Partnerzy · Distributors · Agenci · White-label · Multi-region

Co dostajesz w cenie aplikacji webowej DV

UX dopasowane do realnego workflow, nie do design trendów

Wiesz wcześniej niż użytkownik gdy coś nie działa

Aplikacja, do której dodaje się funkcje, a nie przepisuje

Bezpieczeństwo niewidoczne dla użytkownika, ale obecne

Stack technologiczny dla aplikacji webowych

Next.js + React Server Components + Tailwind

Node.js + TypeScript + PostgreSQL + Prisma

Auth dobierany pod model biznesowy aplikacji

Infrastruktura dobierana pod skalę i wymogi

Od konsultacji do produkcji — etapami

Ile kosztuje aplikacja webowa

30 - 60 tys. zł

Pojedynczy moduł, 1-2 role użytkowników

60 - 120 tys. zł

3-5 ról, integracje, prosty multi-tenant

120 - 300+ tys. zł

Multi-tenant SaaS, compliance, advanced features

Co najmocniej decyduje o cenie aplikacji webowej

Czego nie obejmują nasze widełki

Co NIE jest w cenie projektu

3 rzeczy, które robimy inaczej w aplikacjach webowych

Architektura multi-tenant nawet dla single-tenant projektów

Staging od sprintu 1, monitoring przed launchem, zero „big bang"

Kod w Twoim repo od pierwszego sprintu, zero proprietary DV libraries

Dla kogo budujemy aplikacje webowe — i dla kogo nie

Firma 30-150 osób, custom system jako must-have

Gotowy SaaS pokrywa 70%+ Twoich potrzeb

Startup post-MVP, refactor lub rebuild pod scale

Lean MVP za 10-20 tys. zł / proof-of-concept w tydzień

Firma 100-300 osób, outsourcing modułu większego systemu

Enterprise 500+ pracowników, budżet 1+ mil. zł, multi-region

Pytania, które dostajemy w fazie konsultacji

01|MULTI-TENANCYKiedy aplikacja powinna być multi-tenant, a kiedy single-tenant wystarczy?

02|SCALING I PERFORMANCECo się stanie gdy aplikacja urośnie z 100 do 10 000 użytkowników?

03|VENDOR LOCK-INCzy stack DV (Next.js + Payload) tworzy vendor lock-in?

04|COMPLIANCE Czy DV buduje aplikacje pod RODO Art. 9 (medycyna), KNF (finanse) lub SOC2?

05|MIGRACJA Z LEGACYCzy DV migruje istniejące aplikacje (PHP legacy, stary .NET, custom enterprise)?

06|MOBILE Czy do aplikacji webowej można później dodać aplikację mobilną?

07|DEPLOYMENT Czy aplikacja musi być na serwerach DV, czy mogę hostować u siebie?

Kiedy aplikacja webowa zwraca się szybciej niż gotowy SaaS

Wdrożony SaaS wymusza zmianę procesu zamiast wspierać

Dane między systemami przepływają przez ludzi, nie API

Klient B2B oczekuje samoobsługi, my obsługujemy mailowo

Decyzje zarządcze na podstawie spóźnionych raportów Excel

Co konkretnie budujemy

SaaS multi-tenant — od MVP do produktu

Multi-tenant · Subskrypcje · Auth · Białe-label · Scaling-ready

Dashboard zarządczy z real-time data

BI · Agregacja danych · Self-service drill-down · Alerty

Dashboard zarządczy z real-time data

BI · Agregacja danych · Self-service drill-down · Alerty

Custom CRM dla branż, których nie obsługuje gotowy SaaS

Workflow · Pipeline · Integracje · Branża-specific

B2B portal partnerski dla firm 100-300 osób

Partnerzy · Distributors · Agenci · White-label · Multi-region

Co dostajesz w cenie aplikacji webowej DV

UX dopasowane do realnego workflow, nie do design trendów

Wiesz wcześniej niż użytkownik gdy coś nie działa

Aplikacja, do której dodaje się funkcje, a nie przepisuje

Bezpieczeństwo niewidoczne dla użytkownika, ale obecne

Stack technologiczny dla aplikacji webowych

01MULTI-TENANCY
Kiedy aplikacja powinna być multi-tenant, a kiedy single-tenant wystarczy?

02SCALING I PERFORMANCE
Co się stanie gdy aplikacja urośnie z 100 do 10 000 użytkowników?

03VENDOR LOCK-IN
Czy stack DV (Next.js + Payload) tworzy vendor lock-in?

04COMPLIANCE
Czy DV buduje aplikacje pod RODO Art. 9 (medycyna), KNF (finanse) lub SOC2?

05MIGRACJA Z LEGACY
Czy DV migruje istniejące aplikacje (PHP legacy, stary .NET, custom enterprise)?

06MOBILE
Czy do aplikacji webowej można później dodać aplikację mobilną?

07DEPLOYMENT
Czy aplikacja musi być na serwerach DV, czy mogę hostować u siebie?

01MULTI-TENANCY
Kiedy aplikacja powinna być multi-tenant, a kiedy single-tenant wystarczy?

02SCALING I PERFORMANCE
Co się stanie gdy aplikacja urośnie z 100 do 10 000 użytkowników?

03VENDOR LOCK-IN
Czy stack DV (Next.js + Payload) tworzy vendor lock-in?

04COMPLIANCE
Czy DV buduje aplikacje pod RODO Art. 9 (medycyna), KNF (finanse) lub SOC2?

05MIGRACJA Z LEGACY
Czy DV migruje istniejące aplikacje (PHP legacy, stary .NET, custom enterprise)?

06MOBILE
Czy do aplikacji webowej można później dodać aplikację mobilną?

07DEPLOYMENT
Czy aplikacja musi być na serwerach DV, czy mogę hostować u siebie?