Prezentacja podsumowuje to, czego nauczyliśmy się pisząc Fluksa oraz muu.sk. Informacje w niej zawarte dla niektórych mogą okazać się dosyć oczywiste, dla innych – np. młodych wilków – mogą okazać się pomocną wskazówką. Wszystko zależy od stopnia zaawansowania wiedzy technologiczno-startupowej.

Udanego odbioru.

16 grudnia (wtorek) w Krakowie odbędzie się Krakspot #3, podczas którego zostanie przeprowadzony konkurs startupów. Z naszej strony zaprezentujemy Fluksa w 5-minutowej formule elevator pitch oraz zmierzymy się z opinią zaproszonych komentatorów. Warto też zapoznać się z innymi prezentacjami, które pojawią się tego wieczoru.

W najbliższą sobotę, 20 grudnia pojawimy się na świątecznej edycji szczecińskiej imprezy Netcamp. Podczas prezentacji “Flux, czyli czego nauczył nas startup” opowiemy o naszych doświadczeniach, które zdobyliśmy tworząc przez kilkanaście miesięcy naszą aplikację. Skupimy się na ogólnych przemyśleniach, które można odnieść do dowolnego startupu internetowego.

Do zobaczenia w Krakowie oraz Szczecinie!

Impreza obowiązkowa dla każdego, kogo interesuje jak robić biznes w internecie. Jak łatwo się domyślić, targi organizowane są przez ekipę Netguru, znaną między innymi z cyklu imprez Barcamp.

Pojawimy się na tej imprezie i przedstawimy nasz projekt o kodowej nazwie Flux. Na wrocławskiej imprezie StartupShow opowiedzieliśmy o nim dosyć obszernie. Tym razem będzie okazja, aby poznać esencję Flux’a. Podczas 5-minutowego elevator pitch pierwszy raz publicznie pokażemy demo działającej aplikacji.

Podczas rozmów przedstawiliśmy nasz drugi, większy projekt o kodowej nazwie “Flux”. Wzbudził on zainteresowanie inkubatora i po kolejnej rozmowie doszliśmy do porozumienia odnośnie warunków współpracy.

Flux jest aplikacją webową wspierającą współdzielenie informacji oraz pracę grupową. Składa się z zintegrowanych modułów poczty, kontaktów oraz kalendarza. Dodatkowo posiada prosty i funkcjonalny moduł CRM. Więcej o Flux’ie możecie dowiedzieć się z prezentacji, która odbyła się na imprezie StartupShow we Wrocławiu.

Celem naszej współpracy jest finalizacja wersji beta produktu, działania marketingowe oraz uruchomienie międzynarodowej sprzedaży produktu. Pomogą nam w tym ludzie odpowiedzialni na sukcesy takich projektów jak Monetto.pl, Bankier.pl czy dostępnego na całym świecie projektu Livechat.

Nasza aplikacja była pretekstem do opowiedzenia ciekawej historii, jak spontaniczne decyzje oraz małe sprawy potrafią wywołać niespodziewane efekty, czyli przysłowiowy efekt motyla.

Rozumiem, że formuła Pecha Kucha bez backgroundu słownego nie jest wybitnie czytelna, jednak pojawiały się głosy o udostępnienie tej prezentacji, stąd umieszczam ją w oryginalnej formie. Jak udało mi się dowiedzieć, na stronie Barcampu za jakiś czas pojawią się nagrania wideo.

Pierwsza strona prezentacji “Czy warto było stworzyć muu.sk w 24h?”

Stosując formułę Pecha-Kucha, opowiemy o naszych doświadczeniach, związanych z uczestnictwem w konkursie Hackfest z projektem muu.sk. Obiecujemy interesujące 6 minut i 40 sekund dla każdego, kto interesuje się tematem startup-ów.

Warto wspomnieć, iż gościem głównym będzie Jacek Gadzinowski, który odpowie na pytania zadawane przez Was w komentarzach do wpisu informującego o sobotnim Barcamp-ie.

Do zobaczenia w sobotę!

UPDATE: Zmieniła się nazwa prezentacji. Pierwsza strona slajdów jest już nieaktualna.

Poniedziałek był dniem, w którym po raz pierwszy przyszło nam rozmawiać z inwestorem w sprawie naszego spontanicznego projektu muu.sk. Nasunęło mi się kilka refleksji, które mogą okazać się przydatne dla tych wszystkich, którzy po raz pierwszy wybierają się takie spotkanie, lub planują się wybrać w najbliższym czasie.

Nastaw się pozytywnie

Ludzie, którzy siedzą “po drugiej stronie” często zaczynali podobnie jak Ty – kończyli szkoły, zakładali własne firmy oraz szukali finansowania. Razem z Tobą chcą zarobić na projekcie. Często gdyby nie oni, wiele projektów nigdy nie zostało do zakończonych. Nie należy ich traktować jako zło konieczne, a raczej jako partnerów, którzy pomogą Ci osiągnąć sukces. Z takim właśnie podejściem pojechaliśmy do Wrocławia, efektem czego była sympatyczna i rzeczowa rozmowa.

Podziel się pomysłem

Jeśli myślisz, że masz unikalny pomysł wart grube miliony, najprawdopodobniej nie masz racji. Same pomysły są niewiele warte, stąd ludzie zaczynają o nich mówić publicznie. To co faktycznie się liczy to team, wykonanie oraz trochę szczęścia. W naszym przypadku rozmowa z inwestorem o projekcie przyniosła dużo ciekawych pomysłów oraz garść nowej funkcjonalności do zaimplementowania w przyszłości.

Weź wizytówki

Inwestor to nie tylko pieniądze – to także wiedza oraz kontakty. Szerokie znajomości w branży na pewno ułatwią pozyskanie finansowania, pierwszych klientów lub chociaż cennego feedback’u od osób doświadczonych w IT. Niezależnie jak duża jest Twoja firma lub team, przygotuj sobie schludne wizytówki pamiętając, że im są one prostsze, tym lepiej. Bardzo możliwe, że spotkanie rozpocznie się właśnie od ich wymiany.

Nie zapisałeś? Zapomnisz

Podczas rozmowy pada wiele pytań, wątki potrafią się toczyć symultanicznie. Jeśli bardzo chcesz o czymś powiedzieć, umieść to w swoich slajdach. Inaczej najprawdopodobniej zapomnisz o tym wspomnieć.

Lepiej powiedz za dużo, niż za mało

W naszym przypadku spontanicznie rozwinęliśmy temat naszej flagowej aplikacji (nadal w fazie testów), która miała być dowodem na kompetencje naszego zespołu. Co ciekawe, temat wzbudził zainteresowanie i znów – cenny feedback, nowe możliwości oraz zaproszenie na kolejne spotkanie.

A Wy o czym byście radzili pamiętać?

Nasz startup – muu.sk – drogą głosowania zajął drugie miejsce w konkursie Hackfest.

Chwilę po ogłoszeniu wyników z czekiem na milion $ ;)
Od lewej: Wiktor, Jacek, Paweł.
Foto: Michał Adamczak

Miło nam również wspomnieć, iż muu.sk został dodatkowo wytypowany przez Venture Incubator jako jeden z trzech projektów, który zostanie poddany biznesowej ewaluacji w ramach inkubatora.

Dziękujemy za pozytywny feedback, opinie oraz sugestie dotyczące dalszego rozwoju. Dobrze upewnić się, że problem zapominania nie dotyczy tylko nas samych.

Oficjalny blog aplikacji znajduje się pod adresem blog.muu.sk. Znajdziecie tam informacje o tym co aktualnie dzieje się w naszym laboratorium, spisane przez jednego z laborantów…

Update: na stronie Hackfestu pojawiły się oficjalne wyniki konkursu.

Dokładnie tydzień temu zakończył się poznański “Hackfest”. Została już opisana w wielu miejscach, jednak dla tych, którym nie udało się o niej usłyszeć (są tacy?) słowo wytłumaczenia.

Nasz team podczas pracy (od lewej): Wiktor, Jacek, Paweł.
Stolik w kolorach Microsoft Office oraz Google Chrome ;)
Autor zdjęcia: Bartek Raciborski (webstop.pl)

Hackfest to impreza, której ideą jest zebranie 2-3 osobowych grup programistów, którzy mają 24h na napisanie prototypu aplikacji webowej według własnego pomysłu. Podczas pisania wolno korzystać z ogólnodostępnych bibliotek, frameworków oraz napojów energetycznych. Trudno wymagać, aby w dobę powstały rozbudowane serwisy, jednak w tym przypadku bardziej liczą się pomysły i dobra zabawa, niż coś więcej niż “public beta”.

Jak się okazuje w 24 godziny można zrobić naprawdę dużo, czego dowodem są zarówno napisane aplikacje, jak i kolejne epizody przygód Jack’a Bauer’a, głównego bohatera popularnego serialu 24.

Jak było?

Trzeba przyznać, że ekipa Netguru przygotowała wszystko na wysokim poziomie, zadbała m.in. o:

• klimatyzowaną salę poznańskiego UAM’u,
• przestronne biurka,
• czekoladowe paluszki (jak te słone, tylko że w czekoladzie – hit!),
• świeżą i ciepłą pizzę co kilka godzin,
• nielimitowaną wodę, colę oraz interesująco nazwany napój energetyczny,
• 99,9% uptime serwerów

Ważna informacja dla pracodawców – okazuje się, że programiści oraz graficy mogą pracować trzy razy dłużej, niż mają to w zwyczaju ;)

Osobiście byłem przekonany, że padnę koło 3-4 w nocy. Wiedząc z doświadczenia, że im więcej dziwnych napojów wypiję, tym szybciej osiągnę stan ostatecznego ogłupienia, zakończyłem na jednym energetyku i kilku colach, plus ok. 3 litry wody. Po imprezie doszedłem do wniosku, że zgrany team oraz ciekawy projekt działa lepiej niż kofeina oraz inne wynalazki.

Co napisaliśmy?

Nasz projekt nazwany pierwotnie “moo.sk“, zmienił w między czasie nazwę na “muu.sk” (czyt. “mózg”). Wkrótce na blogu przedstawię mroczną historię tego wydarzenia…

Aplikacja rozwiązuje problem zapominania, komu (lub od kogo) pożyczamy przedmioty, takie jak płyty CD, książki oraz wszystko inne, co nadaje się do pożyczenia. Idea jest prosta – zapisujemy co pożyczamy, komu oraz na jak długi okres, a system przy pomocy mail’a powiadamia zainteresowane strony o zbliżającym się terminie zwrotu (lub przypomina, że termin minął). Proste i funkcjonalne, prawda?

Ekran powitalny na muu.sk

Co dalej?

Możecie głosować na aplikacje, które podobają się Wam najbardziej, używając poniższego buttona:



Głosowanie kończy się 19 września (piątek) o godzinie 29:59.

Przeglądając strony internetowe aplikacji z segmentu B2B, zacząłem zwracać uwagę na sposób udostępniania tych aplikacji dla klienta docelowego. Patrząc od strony autorów aplikacji, zazwyczaj proponowane są następujące warianty:

• własny hosting aplikacji,
• instalacja na serwerze klienta.

Obydwa rozwiązania posiadają plusy oraz minusy, które przedstawiłem poniżej.

Powyżej pierwszy produkcyjny serwer Google’a
Zdjęcie pochodzi ze strony Takuya Oikawa, Flickr “Computer History Museum”

Plusy własnego hostingu

1. Wszystko w jednym miejscu – niezależnie od liczby klientów, aplikacja fizycznie znajduje się na Twoim własnym serwerze. Bez względu na to, czy jest to Twoja własna serwerownia czy profesjonalna usługa zewnętrzna, wszystko czym należy się opiekować znajduje się na jednej (lub wielu w przypadku dużego obciążenia) maszynie. Odpada problem logistyczny, który pojawi się, gdy mamy kilkudziesięciu klientów rozrzuconych po całej Polsce. Wprawdzie można łączyć się zdalnie do serwerów, jednak to nie rozwiązuje innych kwestii. Nie każdy klient posiada serwer, inny będzie chciał dokupić nowy i finalnie się okaże, że klient może i kupi nasz software, jednak będzie trzeba do niego pojechać i kompleksowo rozwiązać problem, co może nie uda się wykonać w ciągu jednego dnia.

2. Bezpieczeństwo kodu – Twój cenny kod znajduje się na jednej maszynie i ryzyko jego kradzieży drastycznie spada. Pomimo, iż kod można zabezpieczyć na różne sposoby, nadal mogą się znaleźć chętni do popełnienia przestępstwa. Łatwiej też skontrolować, czy faktycznie aplikację używa tyle osób, na ile została wykupiona licencja.

3. Łatwiejszy update aplikacji – nie trzeba wysyłać skryptów aktualizacyjnych ani martwić się różnice w wersji oprogramowania między różnymi klientami. Update wykonujemy na jednej maszynie i bezboleśnie wszyscy nasi klienci łączą się z najnowszą wersją naszego software’u.

4. Święty spokój klienta – Klient będzie wniebowzięty, gdy usłyszy, że nie musi się martwić o koszt zakupu, konserwacji oraz modernizacji sprzętu. Będzie mógł skupić się na swoim biznesie i korzystać z usług, które mają mu w tym pomóc, zamiast zastanawiać się dlaczego znów trzeba dokupić kolejny serwer.

5. Aplikacje online to przyszłość – a już na pewno zaawansowana teraźniejszość. Poczta elektroniczna, programy biurowe i cała masa oprogramowania dla firm jest dostępna online. O plusach takiego rozwiązania nie trzeba pisać – dość powiedzieć, że potentat na rynku – firma Google – od dawna dostrzega tę alternatywę wobec aplikacji stacjonarnych. Nawet Microsoft, posądzany o przespanie ery internetu, w końcu na poważnie wchodzi do gry, udostępniając swoje usługi dla firm online. Więcej o możliwościach pakietu Microsoftu znajdziecie w notce na blogu Antyweb.

6. Spójne środowisko pracy – Załóżmy, że nasza aplikacja wymaga PHP w wersji 5.1.x z doinstalowaną listą modułów, zainstalowanej Javy oraz bazy danych PostgreSQL w wersji co najmniej 8.x. Nasz klient żyje w świecie PHP4 i MySQL 4.x i nie rozumie, dlaczego to wszystko trzeba zmieniać, skoro “przecież działa”. Oczywiście decydując się na naszą aplikację wie, jakie wymagania trzeba spełnić, ale wszyscy w firmie (łącznie z administratorem) boją się ruszyć archaiczną, firmową bazę danych z obawy przed katastrofą podczas migracji. Niewątpliwie, takie warunki nie będą sprzyjać sprzedaży naszej aplikacji.

Minusy własnego hostingu

1. Duży koszt początkowy – kupno serwera lub jego dzierżawa kosztuje sporo, dodatkowo trzeba ponosić miesięczne koszty umieszczenia go w porządnej serwerowni. Oczywiście, można tworzyć własną serwerownię, lecz o minusach takiego rozwiązania pisał już Paweł Fornalski na swoim blogu. Do tego dochodzi koszt osoby, która serwerem będzie administrować i zaczyna się zbierać spora stała suma miesięczna. Trzeba się liczyć z faktem, że pierwsze sprzedaże (zakładając opłatę abonamentową) pokryją tylko koszty utrzymania serwera i na wypłatę może nie zostać nic. Z drugiej strony przekroczenie tego miesięcznego progu finansowego w firmie to mały sukces, który śmiało można świętować.

2. Problem bezpieczeństwa danych – tutaj sprawa jest prosta. Jeśli dane klienta przepadną, jest po Tobie. Na szczęście problem ten można rozwiązać za pomocą automatycznego backup’u danych. Drugi aspekt to kwestia podejścia klienta do przechowywania danych firmowych poza firmą. W przypadku pisanej przez nas aplikacji, byłyby to głównie emaile, kontakty oraz kalendarze. Z moich obserwacji wynika, że nie każdy się zgodzi na takie rozwiązanie i woli, gdy dane te znajdują się na ich prywatnym, firmowym serwerze.

3. Szybkość działania – aplikacja używana w firmie w sieci lokalnej zazwyczaj działa szybciej, niż połączenie ze zdalnym serwerem. Pomimo optymalizacji kodu i bazy danych, stosowania AJAX’a w trosce o lżejsze odpowiedzi z serwera czy włączenia cache’u, nie będziemy szybsi od firmowego LAN’a na kablu.

4. Brak bezpośredniego kontaktu z klientem – na nic zdadzą się najlepsze CRM’y, gdy nie nawiążemy rzeczywistego kontaktu z klientem, aby poznać jego cele i potrzeby biznesowe. Kontakt z klientem twarz-w-twarz pozwala budować z nim lepsze relacje, niż miałoby to miejsce zdalnie, na przykład przez telefon. Możliwość zadawania pytań podczas kilku godzin wdrażania produktu może też okazać się cenniejsze niż tradycyjne metody badań marketingowych.

5. Problem awarii serwera – gdy Twoja komórka bez przerwy dzwoni a poczta jest przeciążona, może to oznaczać, że Twój serwera padł a Twoi klienci nie mogą korzystać z aplikacji, która jest ich głównym narzędziem pracy. W przypadku instalacji na serwerze klienta X, awaria jego serwera nie ma wpływu na dziesiątki (lub setki) Twoich klientów – oni wciąż mogą pracować na swoich kopiach. W przypadku własnego hostingu, awaria serwera dotyczy wszystkich Twoich klientów jednocześnie. Warto w takim przypadku opanować podstawy działania w przypadku sytuacji kryzysowych :)

Które rozwiązanie jest lepsze?

Trudno jednoznacznie ocenić, które rozwiązanie jest lepsze. W naszym przypadku, najbardziej prawdopodobne jest rozpoczęcie działalności instalując aplikację na serwerach u klienta, by wraz z zwiększeniem przychodów zacząć proponować własny hosting, który wydaje się mniej problematyczny.

Jakie rozwiązanie sam preferujesz? Zapraszam do dyskusji w komentarzach.