Jak jedna osoba zastąpiła narzędzie za 40 tys. dolarów rocznie czymś, co zbudowała w jeden dzień

Marta prowadziła operacje w 30-osobowej firmie logistycznej w Guadalajarze. Jej zespół używał firmowej platformy do zarządzania projektami, która kosztowała ich około 40 000 dolarów rocznie — licencjonowanie za stanowisko, wyższy plan za funkcje raportowe, plus konsultant, którego zatrudnili dwa lata temu do skonfigurowania początkowych przepływów.

Oto rzecz, której nikt w zespole nie chciał powiedzieć na głos: używali może 15% tego.

Kierowcy rejestrowali w narzędziu swoje dzienne trasy. Dyspozytorzy sprawdzali tablicę Kanban, by zobaczyć, kto jest dostępny. Marta wyciągała tygodniowy raport pokazujący dostawy na czas i otwarte problemy. To wszystko. Wykresy Gantta, równoważenie zasobów, planowanie sprintów, śledzenie czasu i panele portfela? Nikt ich nie dotykał. Płacili za scyzoryk szwajcarski, żeby otwierać koperty.

Moment, w którym zaskoczyło

Odnowienie umowy wypadało w lutym. Marta od ponad roku wmawiała sobie, że przeniesie się na coś tańszego „w przyszłym kwartale”. Ale tym razem znajomy, który prowadził małą markę e-commerce, powiedział jej coś, co zapadło w pamięć: „Przestałem szukać właściwego narzędzia i po prostu opisałem AI, czego potrzebuję. Zbudowało to.”

Marta nie była programistką. Kiedyś zrobiła kurs Pythona i porzuciła go po trzecim tygodniu. Ale rozumiała własne procesy lepiej niż ktokolwiek. Potrafiła dokładnie opisać, czego potrzebuje jej zespół, bo żyła wewnątrz tych procesów każdego dnia.

Postanowiła spróbować zbudować zamiennik sama, zanim podpisze odnowienie.

Co właściwie zbudowała

Marta usiadła w sobotni poranek z kreatorem aplikacji z AI i zaczęła opisywać, czego potrzebuje, element po elemencie.

Ekran rejestrowania tras. Kierowcy musieli się meldować na początku zmiany, widzieć przypisane przystanki i oznaczać każdy jako zakończony. Bez przeciągania i upuszczania wykresów Gantta — tylko lista z polami wyboru i znacznikiem czasu. Opisała to prostym hiszpańskim i patrzyła, jak kreator generuje działający interfejs z bazą danych pod spodem.

Panel dyspozytora. Jedna strona pokazująca, którzy kierowcy są aktywni, ile przystanków im zostało, oraz oznaczony kolorem wskaźnik tego, czy są na czas. Marta opisała logikę: zielony, jeśli ukończyli co najmniej 60% przystanków do południa, żółty, jeśli między 40 a 60%, czerwony poniżej tego. Kreator przełożył to na formatowanie warunkowe i widok aktualizujący się na żywo.

Tygodniowy raport. Liczby, które Marta naprawdę wyciągała w każdy piątek: łączna liczba dostaw, procent dostaw na czas, problemy zgłoszone przez kierowców (jak zły adres albo nieobecny klient) oraz porównanie z poprzednim tygodniem. Poprosiła kreator o wygenerowanie tabeli podsumowującej i prostego wykresu słupkowego. Zrobił to.

Prosty tracker problemów. Gdy kierowca coś zgłaszał — zły adres, uszkodzona paczka, skarga klienta — musiało to trafić gdzieś, gdzie Marta mogła to zobaczyć i przypisać. Nie pełny system zgłoszeń. Po prostu lista ze statusem (otwarte / w toku / rozwiązane) i możliwością dodania notatki.

Całość zajęła jakieś osiem godzin rozłożonych na sobotę. Nie dlatego, że którykolwiek element był trudny, lecz dlatego, że Marta wciąż dopracowywała. Pierwsza wersja panelu dyspozytora pokazywała zbyt dużo danych. Przycięła go. Ekran rejestrowania tras potrzebował opcji „pomiń przystanek”, o której początkowo nie pomyślała. Dodała ją, opisując zmianę.

Co tak naprawdę kupowało 40 000 dolarów

Gdy Marta porównała swoją czteroekranową aplikację z firmową platformą, przepaść była oczywista — ale nie w kierunku, którego się spodziewała.

Firmowe narzędzie miało setki funkcji i wymagało konsultanta do konfiguracji. Aplikacja Marty miała cztery ekrany, które mapowały się bezpośrednio na to, jak jej zespół już pracował. Bez potrzeby szkolenia. Bez długu konfiguracyjnego.

Ale prawdziwym kosztem firmowego narzędzia nigdy nie była subskrypcja. To były tarcia, które jej zespół obchodził każdego dnia. Dyspozytorzy koordynowali przez WhatsAppa, bo aplikacja mobilna platformy wymagała czterech dotknięć, by zaktualizować status dostawy. Marta prowadziła osobny Arkusz Google do tygodniowego raportu, bo wbudowany moduł raportowy wymagał przejścia przez trzy menu, by wyciągnąć te same pięć liczb. Kierowcy zakładkowali obejście w dokumentacji pomocy do ekranu rejestrowania tras, bo domyślny przepływ zakładał fazy projektu, których nie używali.

Aplikacja Marty nie miała obejść, bo została zbudowana z obejść. Każdy ekran istniał, bo ktoś w zespole robił to zadanie nieformalnie — na WhatsAppie, na arkuszu, na tablicy — a Marta po prostu opisała kreatorowi tę nieformalną wersję.

Części, które ją zaskoczyły

Trzy rzeczy, których Marta się nie spodziewała:

Iteracja była szybka. Gdy kierowca zasugerował dodanie pola notatek do każdego przystanku, Marta opisała zmianę kreatorowi podczas przerwy na lunch i wdrożyła ją tego samego popołudnia. Przy firmowym narzędziu zmiany takie jak ta przechodziły przez kolejkę zgłoszeń do supportu i czasem zajmowały tygodnie.

Jej zespół przyjął to od razu. Bez sesji szkoleniowych. Bez „proszę obejrzeć ten film wprowadzający”. Dyspozytorzy otworzyli to w poniedziałek rano i zrozumieli, bo wyglądało jak tablica, której używali nieformalnie, tylko cyfrowa.

Wciąż to ulepszała. Przez kolejne dwa tygodnie dodała piąty ekran: widok miesięczny dla swojego szefa pokazujący trendy dostaw i szacunki kosztu na trasę. Przy firmowym narzędziu byłoby to zapytanie o niestandardowy raport. Przy własnej aplikacji była to 20-minutowa rozmowa z kreatorem.

Czym to nie jest

To nie jest historia o tym, że firmowe oprogramowanie jest złe. Jeśli jesteś 500-osobową firmą prowadzącą złożone projekty międzydziałowe z zależnościami, ograniczeniami zasobów i wymogami zgodności, prawdopodobnie potrzebujesz tego scyzoryka szwajcarskiego.

Ale jeśli jesteś 30-osobowym zespołem używającym 15% narzędzia, które kosztuje więcej niż jeden z Twoich pracowników, coś jest źle dopasowane. Narzędzie nie jest problemem — niedopasowanie jest.

A to niedopasowanie kiedyś było nieuniknione. Zanim mogłeś zbudować aplikację bez programowania, Twoje wybory były takie: płacić za duże narzędzie, sklecić coś w arkuszach albo zatrudnić programistę do zbudowania niestandardowego oprogramowania (co wprowadza własne koszty i terminy). Teraz jest czwarta opcja: opisać, czego potrzebujesz, i zbudować to sam.

Matematyka

Liczby Marty po miesiącu:

• Firmowe narzędzie: ~3300 dolarów miesięcznie (40 tys. rocznie)
• Subskrypcja kreatora aplikacji z AI: poniżej 100 dolarów miesięcznie
• Czas budowy: 8 godzin (jedna sobota)
• Czas iteracji: 20–30 minut na zmianę
• Czas adopcji przez zespół: zero — załapali to pierwszego dnia

Nie potrzebowała CTO ani zespołu inżynierów. Potrzebowała opisać, jak jej zespół naprawdę pracuje — i kreatora aplikacji z AI, który zamienił ten opis w działające oprogramowanie.

O czym warto pomyśleć

Jeśli rozpoznajesz własną sytuację w historii Marty, oto przydatne ćwiczenie przed następnym odnowieniem oprogramowania: zapisz każdą funkcję, której naprawdę używasz w obecnym narzędziu. Nie funkcje, których uważasz, że powinieneś używać, albo planujesz używać kiedyś. Te, których Twój zespół dotyka co tydzień.

Jeśli ta lista mieści się na karteczce samoprzylepnej, możesz przepłacać za złożoność, której nie potrzebujesz.

Nie musisz budować zamiennika w jeden dzień. Mógłbyś zacząć od jednego ekranu — tego, który liczy się najbardziej — i zobaczyć, jak to jest. Koszt spróbowania to kilka godzin. Koszt niespróbowania to kolejny rok płacenia za funkcje, których nigdy nie dotkniesz.

Jeśli chcesz zobaczyć, jak wygląda budowanie własnego narzędzia, wypróbuj Proyecta i zacznij od tego, na co Twój zespół narzeka najbardziej.