Rozwój oprogramowania na zamówienie

Rozwój oprogramowania na zamówienie — budujemy oprogramowanie, którego potrzebuje wasz biznes i którego jako produkt standardowy nie ma. Od małego pomocnika (380-liniowy daemon hardenujący webshop) po złożony system produkcyjny (100 000-liniowa platforma decyzyjna event-driven). Ta sama dyscyplina inżynierska, skalowana do problemu.

Pracujemy według praktyk Extreme Programming (XP) — skupionych na tym, co faktycznie produkuje działające oprogramowanie: Pair Programming, Test-Driven Development, Continuous Integration, Refactoring i bezpośrednia współpraca z klientem. Nie ceremonialnie przeładowani krewni (Scrum, SAFe, …), przy których rytuały stają się ważniejsze niż działający kod.

  flowchart LR
    A[Realny problem] --> B[Discovery + pair-design]
    B --> C[Iteracja 1-2 tygodnie]
    C --> D[Testowany release]
    D --> E{"Rozwiązuje?"}
    E -->|jeszcze nie| B
    E -->|tak| F[Przekazanie produkcyjne]
    D -.->|każda zmiana| G[TDD · CI · Refactor]

O co chodzi

Oprogramowanie standardowe od dziesięcioleci pokrywa oczywiste 80 % potrzeb biznesowych. Co zostaje, to 20 % specyficznych dla waszej organizacji — workflows, dla których nikt nie sprzedaje SaaS, integracje między dwoma dostawcami, którzy nie chcą ze sobą rozmawiać, narzędzia operacyjne automatyzujące pracę, której nikt poza firmą nie wie, że ją robicie.

Te 20 % to pole rozwoju oprogramowania na zamówienie. To jest też pole, na którym większość projektów oprogramowania upada — nie dlatego, że technologia jest zła, lecz dlatego, że proces staje się rytuałem, a działający kod kwestią poboczną.

Budujemy te 20 %. Małych pomocników, gdy to potrzebne, złożone systemy, gdy to potrzebne. Ta sama dyscyplina inżynierska, bez ceremonialnego overheadu.

Dlaczego XP, nie Scrum

Nie potrzebujecie przeglądu wszystkich smaków Agile. Krótka wersja:

• Extreme Programming (XP) koncentruje się na praktykach inżynierskich, które bezpośrednio produkują działające oprogramowanie: TDD, Pair Programming, Continuous Integration, Refactoring, współpraca z klientem, małe releases.
• Scrum, SAFe i pokrewne koncentrują się na procesie wokół inżynierii: ceremonie, story points, velocity charts, retrospektywy, rytuały planowania, role „Agile-Coach".

W zdrowej organizacji praktyki inżynierskie produkują wartość, a proces jest lekkim rusztowaniem wokół niej. W wielu organizacjach proces staje się religią, a inżynieria kwestią poboczną. Status reports idą przed działającym kodem; ceremonie wypełniają kalendarz, a system się gnije.

Pracujemy w stylu XP:

• Pair Programming (lub pair-review kodu augmentowanego AI) jest domyślne. Dwie głowy przy każdej znaczącej zmianie.
• TDD — testy pisane najpierw, potem kod. Test jest specyfikacją, która zostaje długo po notatkach z meetingu.
• Continuous Integration — każda zmiana przechodzi przez tę samą pipeline. Bez „ale na mojej maszynie działa".
• Refactoring jest częścią pracy, nie osobnym budżetem. Czysty kod jest tańszy w rozszerzaniu niż brudny.
• Małe releases — cotygodniowo deployowalne artefakty, bez quartalnych big-bangów.
• Customer-on-site — wasz stakeholder jest ciągle w loopie, nie tylko przy sprint-reviews.

Spektrum zaangażowań

Ta sama metodologia skaluje od jednoliniowych utilities po multi-daemonowe systemy produkcyjne. Przykłady z naszego własnego portfolio ilustrują zakres:

• Mali pomocnicy (dni do tygodni). 380-liniowy Perl-daemon ( Abusive HTTP Watch), hardenujący webshopy przeciwko atakującemu ruchowi. Zbudowany w około dwóch tygodniach. W produkcji u kilku sklepów, od ponad roku bez konieczności zmian.
• Średnie systemy (tygodnie do kilku miesięcy). Aplikacja capture powiadomień świadoma prywatności ( Notification Guard) — Tauri + Rust + Svelte, około 10 000 linii. Zbudowana w około czterech tygodniach skoncentrowanej pracy.
• Złożone systemy produkcyjne (miesiące). Realtime platforma decyzyjna event-driven ( Realtime Decision Platform) — około 100 000 linii Python, siedem daemonów, ML-pipeline, multi-tenant. Zbudowana przez około sześć miesięcy.

Ta sama dyscyplina, te same praktyki XP, różne wielkości.

Co dostajesz

• Działające oprogramowanie wcześnie. W ciągu pierwszych 1–2 tygodni zaangażowania działa testowany kod, który robi coś użytecznego — nie tylko slajdy i diagramy architektoniczne.
• Cotygodniowe testowane releases. Każdy tydzień kończy się deployowalnym, testowanym kodem. Możesz zatrzymać zaangażowanie w każdym tygodniu, a to, co jest, jest production-ready.
• Pełna własność na końcu. Kod źródłowy, testy, dokumentacja, runbooks deploymentu — wszystko twoje. Bez opłat licencyjnych, bez kosztów per-seat, bez lock-in na nas.
• Produktywność wspierana przez AI. 8–12× przepustowości konwencjonalnego rozwoju, przy nienaruszonej dyscyplinie review i audit trail. Kod jest sprawdzany przez człowieka; AI jest narzędziem, nie autorem.
• Fixed-price MVP, następnie iteracyjne rozszerzanie. Pierwszy scope jest fixed-price, więc znasz budżet. Potem rozszerzenia są scope’owane per iteracja, każda z własną ceną.

Dlaczego to jest tematem dla CEO

• 💰 Build vs. Buy. Które 20 % budować zamiast kupować, to decyzja strategiczna. Budowanie złych rzeczy jest drogie; kupowanie rzeczy, które powinniście budować, też jest drogie. Funkcja, która dobrze buduje, to funkcja, która czyni „budowanie" wiarygodną opcją w rozmowie build-vs.-buy.
• 📈 Wskaźniki awarii. Dane branżowe: ~60–70 % projektów bespoke-software upada lub zostaje wstrzymanych. Dominującym powodem jest kolaps procesu, nie techniczna niemożliwość. Dyscyplina inżynierska adresuje dokładnie ten powód.
• ⏱️ Time-to-Value. Sześciomiesięczna „transformacja Agile" zanim zostanie zbudowany pierwszy działający kod to sześć miesięcy kosztów alternatywnych. XP dostarcza działający kod w pierwszym tygodniu.
• 🛡️ Kontinuita. Oprogramowanie zbudowane bez ceremonii, ale z testami, refactoringiem i czystym kodem, to oprogramowanie, które może utrzymywać zespół-następca. Oprogramowanie zbudowane z dużą ceremonią i bez testów to oprogramowanie, które jest legacy już pierwszego dnia.
• 🔓 Własność. Posiadacie kod, testy, dokumentację. Bez ukrytych kosztów licencjonowania per-seat, bez decyzji vendora o waszej roadmapie, bez ryzyka, że dostawca zbankrutuje lub strategicznie się przerzuci.
• 🤖 AI to multiplikator, nie autor. Argument produktywności za in-house-build działa tylko, jeśli produktywność jest realna. Inżynieria augmentowana AI z dyscypliną daje mierzalnie 8–12×; AI bez dyscypliny daje wyglądający wiarygodnie kod, który nie działa.

Fundament technologiczny

Pracujemy w językach i stackach wybranych według dopasowania, nie według mody. Właściwy stack jest determinowany przez problem i wasz istniejący krajobraz, nie przez to, co firma konsultingowa akurat zna.

Odezwij się, a naszkicujemy MVP — małą fixed-price pierwszą część — w rozmowie scopingowej.