Inratio
Strategia

Jak podnieść rentowność w software house — przewodnik prezesa

Software house ma teoretyczną marżę 60-80% (stawki godzinowe vs koszty programistów). Realna marża operacyjna polskich software house'ów to 15-30%. Gdzie wycieka 40-50 pp i jak to naprawić.

15 czerwca 2026·Zespół Inratio·10 min czytania

Software house to teoretycznie najlepszy biznes w Polsce — stawki godzinowe 200-500 zł, koszt programisty 60-150 zł/h, marża 60-80%. Realna marża operacyjna polskich software house'ów to 15-30%. Gdzie wycieka 40-50 pp i jak to naprawić w 6-12 miesięcy.

Wyciek 1: Bench (programiści bez projektu) — średnio 15-25% straty

Najwięksi wrogowie marży software house. Programista kosztuje firmę 12-25 tys. zł/mc (pensja + ZUS + benefity + miejsce). Bench = brak billable hours = pełna strata kosztu. Średnio software house ma 15-25% benchu (czyli na 20 programistów, 3-5 nie generuje przychodu).

Przyczyny benchu: (1) Koniec projektu nieskoordynowany z początkiem kolejnego (typowe!); (2) Klient odłożył start o 4-8 tygodni; (3) Programista o niszowych umiejętnościach (nie pasuje do innych projektów); (4) Słaby pipeline sprzedaży.

Fix: pipeline 60-90 dni do przodu. Kalendarz dostępności zespołu vs prognoza projektów. Sprzedaż musi pracować z wyprzedzeniem 60 dni minimum. Programista wychodzi z projektu = nowy projekt już zarezerwowany. Bez tego — 15% benchu zjada 10-15 pp marży.

  • Bench 5-10%: zdrowo, naturalne 'fluktuacje'.
  • Bench 10-15%: ostrzeżenie, słabe planowanie.
  • Bench 15-25%: kryzys, marża spada o 5-15 pp.
  • Bench > 25%: firma traci pieniądze, jeden zły kwartał wpędza w stratę.

Wyciek 2: Przekroczenia czasu projektów (fixed-price na minusie)

Software house podzielony na 2 modele: time & materials (T&M, klient płaci za godziny) i fixed-price (klient płaci stałą kwotę za zakres). T&M ma 'naturalną' obronę przed przekroczeniami. Fixed-price jest miną.

Klasyczny scenariusz: wycena 800h, sprzedaż wymusza 700h żeby wygrać przetarg, projekt realnie wymaga 1100h. Strata: 400h × 100 zł kosztu = 40 tys. zł straty na projekcie + zero marży na sprzedanych 700h.

Fix: agresywna ostrożność w wycenach fixed-price. Margines bezpieczeństwa MIN 25-30% (jeśli oszacowane 800h, wyceniaj 1000h). Twarde zarządzanie zakresem (change request → płatność). Po 20% przekroczeniu — eskalacja do prezesa, decyzja: docisnąć/renegocjować/zaakceptować stratę.

Wyciek 3: Stawki za niskie dla wartości dostarczanej

Polski software house typowo wycenia 200-350 zł/h dla zachodnich klientów. To znacznie poniżej rynkowych stawek 400-700 EUR/dzień (czyli 350-550 zł/h przy kursie 4,4). Pozycjonowanie cenowe trzyma firmę poniżej swojej realnej wartości.

Dlaczego niższe stawki: (1) Historia — software house zaczynał z niższych stawek, klienci się przyzwyczaili, podwyżki idą wolno; (2) Pozycjonowanie — 'jesteśmy polską firmą', sugeruje 'jesteśmy tańsi' nawet jeśli jakość jest na poziomie zachodnim; (3) Sprzedaż nie ma case'ów ROI klientów do uzasadnienia wyższej ceny.

Fix: testuj wyższe stawki dla NOWYCH klientów. Nie podnoś starym (psuje relacje). Każdy kolejny nowy klient — +10-20% wobec poprzedniego. Po 12 miesiącach Twój blended rate (średnia ważona) wzrasta o 15-25%. Marża operacyjna rośnie liniowo.

Wyciek 4: Niedoszacowane utrzymanie / support

Po dostarczeniu projektu klienci wracają z bugami, drobnymi zmianami, pytaniami. Bez osobnego kontraktu na maintenance — Twój zespół spędza 5-15% czasu obsługując stare projekty 'za darmo'.

Konkret: 10 zakończonych projektów × średnio 4h/mc supportu = 40h/mc = 1 pełnoetatowy programista uwięziony w maintenance bez billingu. To 15-25 tys. zł/mc straty bez świadomości.

Fix: po zakończeniu projektu od dnia 1 obowiązuje kontrakt maintenance (oddzielna umowa, oddzielne fakturowanie). Stawka godzinowa zwykle wyższa niż na nowych projektach (mniej przewidywalna praca, gotowość 24/7). Alternatywa: pakiet maintenance 4h/mc × stała stawka. Klient płaci za 'bezpieczeństwo'.

Maintenance który nie jest fakturowany to nie 'usługa po sprzedaży' tylko cichy wyciek 15-25 tys. zł/mc. Pierwszy krok do uzdrowienia: każda godzina zespołu ma swój koszt i klienta.

Wyciek 5: Słaba sprzedaż = drogie nowe projekty

Koszt pozyskania klienta (CAC) w software house to typowo 30-80 tys. zł (sprzedaż, marketing, propozycje, prezentacje, pre-sales). Dla projektu 200-500 tys. zł — to 10-30% CAC/przychód.

Problem: większość software house'ów ma 50-70% pojedynczych projektów (one-shot, klient odchodzi po dostarczeniu). Każdy nowy projekt wymaga ponownego CAC.

Fix: model long-term relationship. Po projekcie aktywnie szukasz dalszych zleceń: rozszerzenie, kolejne moduły, maintenance, advisory. Klient który kupuje 2-3 projekty zamiast 1 — CAC spada z 25% przychodu do 10%. Marża rośnie o 15 pp.

Wyciek 6: Niewykorzystany dział R&D / produkty wewnętrzne

Większość software house'ów mówi 'kiedyś zrobimy własny produkt'. Realnie — nigdy. Programiści są albo na płatnych projektach, albo na benchu (który ucinasz). R&D nie ma kapacitetu.

Strategia która działa: 10-15% czasu zespołu na R&D produktowy (np. piątkowe afternoons + 1 dzień na kwartał). Po 12 miesiącach masz pierwszą wersję produktu wewnętrznego. Po 24 miesiącach — produkt który generuje 5-15% przychodu firmy.

Korzyść strategiczna: produkt to drugi nogi firmy. Software house cash flow zależy od projektów. Produkt SaaS daje powtarzalny przychód (MRR), stabilizuje firmę, zwiększa wycenę przy potencjalnym exicie 2-3x.

Wyciek 7: Brak cotygodniowego pulsu finansowego

Software house ma cykle miesięczne (sprinty, billing, raporty klienta) ale potrzebuje cotygodniowego monitoringu finansowego. Bez tego rozjazd plan vs realność jest widoczny dopiero po 30-60 dniach.

5 KPI do monitoringu tygodniowo: (1) Utilization rate zespołu (% billable); (2) Bench (kto i od ile dni); (3) Przekroczenia czasu projektów aktywnych (plan vs realność); (4) Pipeline sprzedaży (wartość na każdy etap); (5) Cash flow forecast 13 tygodni.

System zarządczy (Inratio) automatyzuje ten puls. Środa 6:00 raport z 5 KPI + alerty (bench > 15%, projekt przekroczył 20% budżetu, pipeline poniżej 90 dni). Programiści logują czas w narzędziu (Toggl, Harvest), Inratio konsoliduje. Bez analityka.

Podsumowanie

Marża software house zależy od 7 dźwigni: bench, przekroczenia projektów, stawki, maintenance, sprzedaż, R&D, cotygodniowy puls finansowy. Wdrożenie wszystkich daje 10-20 pp poprawy marży operacyjnej w 12 miesięcy. Z 15-20% do 25-35% marży operacyjnej dla typowej polskiej firmy 20-50 osób. Klucz: porządek operacyjny przed wszystkim, R&D produktowy jako długoterminowa dźwignia.

Najczęstsze pytania

Jak balansować bench vs przepalenia zespołu?+

Idealny utilization to 75-85%. > 90% = ryzyko burnout, rotacja programistów, jakość spada. < 70% = za drogi bench. Sweet spot 80%: zespół ma czas na review, mentoring, technical debt, ale 80% pracuje billable. Monitoruj tygodniowo, koryguj miesięcznie.

Czy fixed-price w ogóle ma sens dla software house?+

Tylko dla projektów < 600h o bardzo dobrze sprecyzowanym zakresie. Dla większych — T&M albo hybryda (fixed na zakres podstawowy, T&M na rozszerzenia). Klienci często wolą fixed-price, ale software house tracący na fixed-price musi to wbudować w cenę lub odmówić.

Ile programistów na 'sprzedaż' i 'kierownictwo'?+

Benchmark dla software house 20-50 osób: 1 sprzedażowiec na każdych 10 programistów. 1 PM/scrum master na 5-8 programistów. 1 CTO/architekt na 15-20 programistów. CEO + 1 CFO/COO. Czyli typowo 70-80% zespołu to programiści (billable), 20-30% to overhead (sprzedaż, PM, leadership). To pozwala na utilization rate 75-80%.

Te tematy w Twojej firmie — automatycznie

Inratio dowozi cotygodniowy puls firmy z KPI, alertami i decyzjami — dopasowanymi do Twojej branży, bez konfiguracji.

Powiązane artykuły

Wątki, które naturalnie łączą się z tym, co właśnie przeczytałeś.

Sprawdź też