Jak zbudować SaaS w .NET z Claude Code? Case study: MVP w tydzień, Blazor, AI i koszty

Zbudowałem działającą aplikację SaaS w tydzień. Wieczorami, po normalnej pracy. Dziś stoi na produkcji, ludzie z niej korzystają i płacą za nią 79 zł miesięcznie. Prawie cały kod napisałem z Claude Code.

Ale najważniejszej rzeczy w tym projekcie nie zrobiłem w kodzie. Zrobiłem ją pół roku wcześniej, zanim powstała pierwsza linijka. I to jest krok, który większość programistów pomija - dlatego tak wiele aplikacji pisanych po godzinach nigdy nie zarabia ani złotówki.

W tym artykule pokażę Ci całość od środka, na przykładzie mojej aplikacji StrefaWatów - platformy treningowej dla kolarzy amatorów. Zobaczysz, jak działa, dlaczego zacząłem od widowni, a nie od kodu, jak naprawdę wyglądał tydzień pracy z Claude Code (i dlaczego szybko nie znaczyło byle jak), jakie decyzje techniczne podjąłem w .NET i Blazorze, jak bezpiecznie wbudować AI w sam produkt i ile to wszystko kosztuje. Na koniec dostaniesz 5 lekcji, które przeniesiesz na własny projekt.

Stan danych: sierpień 2026. StrefaWatów kosztuje 79 zł miesięcznie po 5-dniowym darmowym okresie próbnym, a plan Claude Code, na którym powstał prawie cały kod, kosztuje mnie ok. 100 USD miesięcznie. Ceny planów AI zmieniają się dość często, więc zanim policzysz własny biznesplan, sprawdź aktualne stawki.

Co zbudowałem: aplikacja StrefaWatów w pigułce

Zanim opowiem, jak to powstało, zobacz, co w ogóle zbudowałem.

StrefaWatów (strefawatow.pl) to platforma treningowa dla kolarzy amatorów. Pomysł jest prosty: wypełniasz ankietę, dostajesz spersonalizowany plan treningowy i codziennie wiesz, co masz robić na rowerze. Bez kombinowania.

Z perspektywy użytkownika wygląda to tak:

• Trening na dziś. Zaraz po zalogowaniu widzisz na pulpicie, co masz dziś zrobić: jaki trening, w jakich strefach i ile czasu.

• Plik treningu do pobrania. Klikasz "pobierz", dostajesz plik treningu, wrzucasz go do Zwifta albo na Garmina - i po prostu jedziesz.

• Kalendarz. Cały miesiąc treningów w jednym widoku, z oznaczaniem ukończonych sesji.

• Wykres formy. Aplikacja na podstawie Twoich aktywności liczy, czy jesteś wypoczęty, czy przemęczony.

Czyli normalny, działający produkt. Nie projekt do szuflady i nie demo na GitHubie, tylko produkt, za który ludzie płacą. I teraz najciekawsze: jak to powstało.

Najważniejsza decyzja: najpierw widownia, potem aplikacja

Większość programistów robi to tak: najpierw miesiącami piszą aplikację, a potem szukają, komu by ją sprzedać. I bardzo często nie sprzedają nikomu. Znasz to? Może sam masz taki projekt w szufladzie.

Ja zrobiłem to na odwrót.

Społeczność przed kodem. Pół roku przed pierwszą linijką kodu założyłem kanał na YouTube "Programista na rowerze" i zacząłem budować społeczność ludzi, którzy jeżdżą na rowerze i interesują się treningiem. Nie miałem jeszcze żadnej aplikacji. Wiedziałem tylko, że będę chciał ją zrobić. Efekt? Klienci byli, zanim powstał produkt.

Kod to dziś łatwa część. To jest kluczowa zmiana w myśleniu. Z AI kod powstaje błyskawicznie. Trudna część to znaleźć ludzi, którzy za niego zapłacą. Skoro tak, to właśnie tym zajmujesz się najpierw - a nie na końcu, kiedy aplikacja jest gotowa i nagle okazuje się, że nikt na nią nie czeka. Widownia nie musi przy tym oznaczać kanału na YouTube. Równie dobrze może to być blog, newsletter czy aktywność w grupie, w której siedzą Twoi przyszli klienci. Ważne, żeby to byli ludzie z Twojej niszy i żeby Cię znali, zanim cokolwiek im zaproponujesz.

Społeczność to darmowy research. Jest też bonus, który łatwo przeoczyć. Kiedy masz wokół siebie ludzi z grupy docelowej, słuchasz ich i widzisz, z czym się męczą. Pytania, które wracają, problemy, o których ktoś pisze drugi i trzeci raz - to gotowa lista funkcji. Kiedy siadasz do kodu, nie zgadujesz, co budować. Ty to już wiesz.

2 rady, jeśli szukasz pomysłu. Jeśli dopiero zastanawiasz się, co zbudować, zacznij od tych 2 rzeczy:

• Celuj w wąską niszę. "Apka dla kolarzy" bije "apkę fitness dla wszystkich". Mniejszy rynek brzmi gorzej, ale łatwiej w nim znaleźć konkretnych ludzi, mówić ich językiem i być w czymś pierwszym.

• Buduj coś, czego sam chcesz używać. Ja jeżdżę na rowerze i z tej aplikacji korzystam codziennie. Jestem swoim pierwszym testerem, więc od razu widzę, co poprawić i czego brakuje.

Tydzień z Claude Code: tempo dało AI, jakość dała dyscyplina

Kiedy usiadłem do kodu, miałem 2 opcje: pisać wszystko samemu, jak przez ostatnie 15 lat, albo zrobić to z Claude Code. Wybrałem Claude Code - i działające MVP powstało w tydzień. Wieczorami, po pracy.

Czym jest Claude Code? Jeśli jeszcze go nie znasz: to agent AI, który działa w terminalu i widzi cały Twój projekt. Nie podpowiada pojedynczej linijki w edytorze, tylko czyta repozytorium, rozumie architekturę i wykonuje całe zadania: tworzy pliki, zmienia kod w wielu miejscach naraz, uruchamia build i testy.

Ale - i to jest najważniejsze zdanie całej tej historii - szybko nie znaczy byle jak. Tempo dało mi AI. Jakość dała dyscyplina. Konkretnie 6 zasad, których trzymałem się przez cały tydzień:

• CLAUDE.md od pierwszego dnia. To plik w katalogu głównym repozytorium, który Claude Code wczytuje automatycznie na starcie każdej sesji. Opisałem w nim konwencje projektu, więc Claude pisał kod po mojemu, a nie po swojemu.

• Plan przed kodem. Większych rzeczy nie wrzucałem jednym promptem. Najpierw plan (tryb Plan Mode albo krótki plik SPEC z opisem funkcji), dopiero potem kod. W Plan Mode, który włączasz skrótem Shift+Tab, agent analizuje projekt i proponuje, co zamierza zrobić, ale nie zmienia żadnego pliku, dopóki nie zaakceptujesz planu.

• Jedna funkcja end-to-end naraz. Szedłem jedną funkcją od bazy danych, przez API, aż po interfejs - i dopiero kiedy działała w całości, brałem następną. Dzięki temu w każdym momencie miałem działającą aplikację, a nie 10 rozgrzebanych kawałków.

• Każdy diff czytany. Zanim zaakceptowałem jakąkolwiek zmianę, czytałem ją w całości.

• Testy na krytycznych ścieżkach. Nie pisałem testów do wszystkiego, tylko tam, gdzie błąd naprawdę boli: płatności, dostęp i logowanie.

• Nic na produkcję bez mojego review. Żadna zmiana nie trafiała na produkcję, dopóki sam jej nie przejrzałem.

Jak może wyglądać CLAUDE.md? Nie musi być długi. Wystarczy, że zawiera to, co inaczej powtarzałbyś agentowi w każdym prompcie. Przykładowy, uproszczony fragment dla projektu w takim stacku:

# Konwencje projektu

## Stack
- Front: Blazor WebAssembly, backend: osobne ASP.NET Core Web API
- Baza: PostgreSQL, hosting: Azure

## Zasady pisania kodu
- Kontrolery są cienkie, logika biznesowa siedzi w serwisach
- Nowa funkcja zawsze end-to-end: baza → API → UI, jedna naraz
- Testy obowiązkowe dla płatności, dostępu i logowania
- Nie dodawaj nowych paczek NuGet bez pytania

## Przed zakończeniem zadania
- Uruchom dotnet build i dotnet test - oba muszą przejść

Do tego dorzucę 2 smaczki z tej budowy.

Subagent do code review. Używałem osobnego agenta tylko do przeglądania kodu. Miał dostęp wyłącznie do odczytu, przeglądał każdą większą zmianę i wypisywał ryzyka, zanim ja w ogóle na nią spojrzałem. Drugie oko za darmo. W Claude Code takiego subagenta definiujesz jako plik Markdown w folderze .claude/agents: w nagłówku podajesz nazwę, opis i listę narzędzi (tu tylko do odczytu), a w treści instrukcję. W uproszczeniu:

---
name: code-reviewer
description: Przegląda większe zmiany w kodzie i wypisuje ryzyka. Użyj po każdej większej zmianie.
tools: Read, Grep, Glob
---
Jesteś doświadczonym reviewerem C#/.NET. Przejrzyj wskazane zmiany i wypisz ryzyka:
błędy logiki, bezpieczeństwo, wydajność, brakujące testy, niezgodność z CLAUDE.md.
Niczego nie zmieniaj - tylko raportuj.

Landing page w kilka godzin. To coś dla każdego backendowca, który nie cierpi frontu. Landing page zrobiłem w kilka godzin, z pomocą skilla do projektowania frontendu (skille to w Claude Code paczki instrukcji, które agent wczytuje, kiedy dostaje zadanie danego typu). Kiedyś ładna, responsywna strona była dla mnie dramatem i walką z CSS-em. Dziś to jedno popołudnie.

I tu jest cała różnica między programistą, który "korzysta z AI", a takim, który z AI pracuje zawodowo. AI jest szybkim wykonawcą. Ty jesteś tech leadem, który odpowiada za jakość.

Architektura MVP: 4 świadome decyzje techniczne

Teraz krótko o technikaliach. Bez zanudzania kodem - same decyzje i powody.

2 aplikacje zamiast 1. Tak naprawdę to są 2 osobne aplikacje. Osobno landing page, który sprzedaje i zbiera maile, osobno właściwa aplikacja, do której logują się użytkownicy. To rozdzielenie bardzo upraszcza życie: stronę sprzedażową możesz zmieniać niezależnie od aplikacji, a każda z nich robi tylko jedną rzecz.

Blazor WebAssembly + osobne Web API. Front napisałem w Blazor WebAssembly, a backend to osobne Web API. Jestem backendowcem i lubię mieć czyste API, które stoi samo: łatwo je testować, a w przyszłości podłączę pod nie choćby aplikację mobilną. Przy okazji logikę po obu stronach piszę w C#, bez przeskakiwania między językami.

Płatności na MVP: zwykły przelew (serio). Tu pewnie Cię zaskoczę. Na start zrobiłem tylko zwykły przelew bankowy, a wpłatę potwierdzam ręcznie w panelu admina. Brzmi prymitywnie? Owszem. Ale dzięki temu nie walczyłem od razu z integracją bramki płatności i testowaniem 10 różnych scenariuszy (płatność udana, odrzucona, zwrot, odnowienie subskrypcji i tak dalej). Stripe i Przelewy24 dołożę, kiedy będzie ruch. Na MVP wybierasz najprostszą rzecz, która działa.

Azure + PostgreSQL (na razie). Szczerze: całość stoi na Azure, a baza to PostgreSQL. Ale pewnie przejdę na SQL Server, bo na Azure wychodzi to o dziwo taniej i lepiej tam działa. Nie każdą decyzję podejmiesz idealnie za pierwszym razem - i to jest okej, o ile umiesz ją później zmienić.

AI w środku produktu: zawsze z bezpiecznikiem

Jedna rzecz, którą polecam każdemu, kto buduje dziś aplikację: dodaj do niej funkcję opartą na AI. To realnie podnosi wartość produktu, a użytkownicy coraz częściej po prostu tego oczekują.

Plan treningowy z AI. U mnie AI siedzi w kilku miejscach, a najważniejsze z nich to wstępne generowanie planu treningowego. Od strony kodu, w skrócie: wołam model, każę mu zwrócić odpowiedź w ustalonym formacie JSON i mapuję ją na zwykły obiekt w C#. Od tego momentu to są normalne dane w aplikacji - zapisujesz je w bazie, wyświetlasz i walidujesz jak wszystko inne.

Plan nigdy nie trafia prosto do użytkownika. A teraz najważniejsze. Wygenerowany plan najpierw ląduje u mnie w panelu admina, gdzie każdy plan ma swój status: Pending → Generated → Approved. Pending czeka na wygenerowanie, Generated to plan od AI, który czeka na mnie, a Approved to plan zatwierdzony. Przeglądam każdy plan i zatwierdzam go albo odrzucam. Klient widzi wyłącznie plan zatwierdzony.

W uproszczeniu cały przepływ wygląda tak (to szkic idei, a nie kod 1:1 z aplikacji):

public enum StatusPlanu { Pending, Generated, Approved, Rejected }

/* 1. AI generuje plan na podstawie ankiety - w ustalonym formacie JSON */
string json = await _ai.WygenerujPlanAsync(ankieta, ct);

/* 2. Mapowanie na zwykły obiekt C# */
var plan = JsonSerializer.Deserialize<PlanTreningowy>(json, _opcjeJson);

/* 3. Bezpiecznik w kodzie: walidacja struktury i wartości */
if (plan is null || !_walidator.CzyPoprawny(plan))
    return Wynik.Blad("AI zwróciło niepoprawny plan");

/* 4. Bezpiecznik ludzki: plan czeka na zatwierdzenie w panelu admina */
plan.Status = StatusPlanu.Generated;
await _repozytorium.ZapiszAsync(plan, ct);

A po stronie klienta wystarczy jeden warunek w zapytaniu:

/* Klient widzi wyłącznie plany zatwierdzone */
var aktualnyPlan = await _db.Plany
    .Where(p => p.UzytkownikId == uzytkownikId && p.Status == StatusPlanu.Approved)
    .OrderByDescending(p => p.DataUtworzenia)
    .FirstOrDefaultAsync(ct);

Uniwersalna zasada: AI proponuje, człowiek zatwierdza. Zapamiętaj to jako regułę na każdy projekt: każda funkcja AI w Twojej aplikacji powinna mieć bezpiecznik. Albo walidację w kodzie (czy odpowiedź ma poprawną strukturę, czy wartości mieszczą się w sensownych zakresach), albo człowieka przed publikacją. Ta sama zasada, która obowiązuje przy pisaniu kodu z AI, obowiązuje w samym produkcie.

Ile to kosztuje i czy się opłaca?

Model biznesowy. Jest prosty: 5 dni za darmo, bez podpinania karty, a potem 79 zł miesięcznie. Subskrypcja to przychód powtarzalny - klient płaci co miesiąc, a nie raz.

Pierwsi klienci bez reklam. Skąd wziąłem pierwszych płacących użytkowników? Ze społeczności, którą zbudowałem wcześniej. Z reklamami nawet nie ruszyłem, bo czekałem na akceptację integracji przez Stravę. I to jest przy okazji osobna lekcja: jak budujesz na cudzej platformie, grasz według jej zasad. Akceptacje, limity, regulamin - wkalkuluj to w plan, bo te terminy nie zależą od Ciebie.

Koszty stałe: grosze. Hosting na Azure plus plan Claude Code - u mnie około 100 USD miesięcznie za plan, na którym powstał prawie cały kod. I tyle. Bez zespołu, bez biura, bez inwestora.

Próg opłacalności. Policz to na chłodno. Wzór jest banalny:

liczba klientów potrzebna do wyjścia na zero = miesięczne koszty stałe ÷ miesięczna cena abonamentu

Wstaw swoje liczby i zobacz, ilu płacących klientów potrzebujesz. Przy tak niskich kosztach stałych zwykle wychodzi kilku, może kilkunastu. Oczywiście dochodzą podatki i Twój czas - ale próg wejścia w taki produkt jest dziś niski jak nigdy w historii.

Jeszcze 2 lata temu zbudowanie czegoś takiego w pojedynkę, po godzinach i w tydzień, było nie do pomyślenia.

5 lekcji z budowy StrefaWatów

Gdybym miał zamknąć ten projekt w 5 punktach, które możesz przenieść na własny pomysł, wyglądałyby tak:

1. Najpierw widownia, potem kod. Znalezienie klienta jest trudniejsze niż napisanie kodu, więc zacznij od trudniejszej części.

2. Z AI kod powstaje szybko - i może być profesjonalny. Z Claude Code kod powstaje naprawdę szybko, a jeśli trzymasz dyscyplinę (CLAUDE.md, plan przed kodem, czytanie diffów, testy, review), jest po prostu dobry.

3. MVP to najprostsza wersja, która działa. Przelew zamiast Stripe'a. Resztę dołożysz później, kiedy będzie po co.

4. Buduj coś, czego sam chcesz używać. Jesteś wtedy swoim pierwszym użytkownikiem i najszybszym testerem.

5. Ty jesteś tech leadem. Zawsze. AI wykonuje. Ty decydujesz, sprawdzasz i bierzesz odpowiedzialność - zarówno za kod, jak i za to, co AI generuje w Twoim produkcie.

Ściąga: decyzje z budowy MVP

Wszystkie najważniejsze decyzje z tego projektu w jednym miejscu:

Podsumowanie

Zbudowanie płatnej aplikacji SaaS w tydzień, wieczorami, jest dziś realne. Ale nie dlatego, że AI zrobi wszystko za Ciebie. Zbierzmy najważniejsze rzeczy:

• Widownia przed kodem: społeczność daje pierwszych klientów i darmowy research.
• Wąska nisza i produkt, którego sam używasz.
• Tempo z AI, jakość z dyscypliny: CLAUDE.md, plan przed kodem, 1 funkcja naraz, każdy diff czytany, testy krytycznych ścieżek.
• MVP = najprostsza rzecz, która działa: przelew zamiast bramki płatności.
• AI w produkcie z bezpiecznikiem: walidacja w kodzie albo człowiek przed publikacją.
• Niskie koszty stałe: do wyjścia na zero zwykle wystarczy kilku-kilkunastu klientów.
• Ty jesteś tech leadem: AI wykonuje, Ty odpowiadasz.

I teraz pewnie myślisz: "okej, fajnie, ale jak ja mam się tego nauczyć?". Dokładnie po to zrobiłem Szkołę 3x Dev. To szkolenie dla programistów C# i .NET, w którym krok po kroku uczę całego workflow opisanego w tym artykule. Od instalacji Claude Code i pierwszego commita, przez prompty, testy i debugowanie, po pełne projekty: landing page w Blazorze i aplikację SaaS od zera aż do wdrożenia na Azure. Bez teorii dla teorii - każdy moduł kończy się działającym kodem w Twoim repozytorium. A w bonusie dostajesz pełne case study StrefaWatów: dłuższą wersję tej historii, ze wszystkimi decyzjami od środka. Masz też gwarancję: 14 dni na sprawdzenie, a jeśli nie zobaczysz różnicy w swojej pracy, oddaję pieniądze.

Zapisy otwieram cyklicznie, więc wejdź na stronę i zostaw maila na liście oczekujących: modestprogrammer.pl/szkola-3x-dev.

Powodzenia z Twoim pierwszym (albo kolejnym) SaaS-em :)