<h6>T&eacute;ma</h6>
<h4>Na zač&aacute;tku každ&eacute; spolupr&aacute;ce se n&aacute;s klient logicky pt&aacute;, co může od v&yacute;voje aplikace čekat &ndash; v jak&yacute;ch kroc&iacute;ch se cel&yacute; proces odehr&aacute;v&aacute;, jak spolu budeme komunikovat a na kolik ho cel&aacute; z&aacute;ležitost vyjde peněz. V tomto čl&aacute;nku se pod&iacute;v&aacute;me zbl&iacute;zka na prvn&iacute; dvě ot&aacute;zky a ceně aplikace a faktorům, kter&eacute; ji ovlivňuj&iacute;, se budeme věnovat v samostatn&eacute;m čl&aacute;nku.</h4>
<p>Nen&iacute; pro n&aacute;s &uacute;plně železn&yacute;m pravidlem, že zač&iacute;n&aacute;me aplikaci vyv&iacute;jet vždy od nuly &ndash; st&aacute;v&aacute; se n&aacute;m taky, že dostaneme do ruky rozdělan&yacute; projekt a m&aacute;me za &uacute;kol ho dot&aacute;hnout. <strong>M&aacute;me pochopen&iacute; pro to, že klient potřebuje dokončit aplikaci</strong> za použit&iacute; technologi&iacute;, ve kter&yacute;ch vznikla, a nemůže si dovolit dosud investovan&eacute; pen&iacute;ze vyhodit oknem. D&aacute;v&aacute; n&aacute;m to smysl z hlediska dlouhodob&eacute;ho vztahu s klientem &ndash; r&aacute;di mu u&scaron;etř&iacute;me pen&iacute;ze. Pro potřeby čl&aacute;nku se ale pod&iacute;v&aacute;me na <strong>v&yacute;voj aplikace od A do Z</strong> a zm&iacute;n&iacute;me n&aacute;sleduj&iacute;c&iacute; t&eacute;mata:</p>
<ul>
<li>Ř&iacute;zen&iacute; projektu metodou waterfall</li>
<li>Proč st&aacute;le častěji dost&aacute;v&aacute; přednost agiln&iacute; v&yacute;voj</li>
<li>Design v pojet&iacute; Koaly</li>
<li>Postupn&eacute; iterov&aacute;n&iacute; aplikace</li>
</ul>
<h5>Ř&iacute;zen&iacute; projektu metodou waterfall</h5>
<p>Někteř&iacute; klienti (vlastně jich je st&aacute;le vět&scaron;ina) otev&iacute;raj&iacute; spolupr&aacute;ci tak, že za softwarovou firmou přijdou s bal&iacute;kem pr&aacute;ce, bal&iacute;kem peněz a ot&aacute;zkou &bdquo;Kdy můžeme aplikaci oček&aacute;vat?&ldquo; Maj&iacute; často velk&yacute; z&aacute;jem o to, aby cenu za v&yacute;voj mohli zafixovat.&nbsp;</p>
<p>Co se ale snaž&iacute;me vždy vysvětlit, je, že s metodou v&yacute;voje zvanou waterfall nen&iacute; možn&eacute; klientovi d&aacute;t přesnou představu, <strong>jak bude vypadat produkt, kter&yacute; vypadne na druh&eacute; straně.</strong> Postupuje se při n&iacute; tak, že se aplikace designuje a programuje v cel&eacute; svoj&iacute; &scaron;&iacute;ři a ke každ&eacute;mu dal&scaron;&iacute;mu kroku se přistoup&iacute;, až když je ten předchoz&iacute; považovan&yacute; za hotov&yacute;.&nbsp;</p>
<h4><img src="https://api.koala42.com/assets/5cd43ab3-9543-4182-9c77-26923757b8a9?width=32&amp;height=25" alt="quotes" /></h4>
<h4>V&yacute;voj aplikace &ndash; ať už webov&eacute;, nebo mobiln&iacute; &ndash; se občas přirovn&aacute;v&aacute; k v&yacute;robě auta. Vodop&aacute;dov&yacute; model v t&eacute;to metafoře od zač&aacute;tku chyst&aacute; z&aacute;vodn&iacute; Ferrari, kter&eacute; klient dlouho vid&iacute; jenom na pap&iacute;ře a projet se v něm může až ke konci projektu.</h4>
<p><img src="https://api.koala42.com/assets/0200508b-392c-4a58-8b56-234b891aa7e9?width=1667&amp;height=667" alt="Vyvoj Aplikace Koala42" /></p>
<h5>Proč st&aacute;le častěji dost&aacute;v&aacute; přednost agiln&iacute; v&yacute;voj</h5>
<p>Agiln&iacute; v&yacute;voj si naproti tomu klade praktick&eacute; c&iacute;le v krat&scaron;&iacute;ch &uacute;sec&iacute;ch &ndash; <strong>sprintech.</strong> Na zač&aacute;tku každ&eacute;ho sprintu, kter&yacute; trv&aacute; 14 dn&iacute;, se definuj&iacute; jednotliv&eacute; d&iacute;lč&iacute; &uacute;koly (tasky) a program&aacute;toři je potom postupně z projektu ukrajuj&iacute;. U agiln&iacute; metody se ned&aacute; z&aacute;vazně ř&iacute;ct, jestli bude cel&yacute; projekt trvat tři měs&iacute;ce, nebo &scaron;est, ale <strong>klient může v&yacute;voj daleko v&iacute;ce ovlivňovat.</strong> Na konci každ&eacute;ho sprintu dost&aacute;v&aacute; report, ve kter&eacute;m vid&iacute;, o jak&yacute; kousek v&yacute;voj zase pokročil kupředu, a může podle potřeby upřesnit zad&aacute;n&iacute;.&nbsp;</p>
<p>Pokud se vr&aacute;t&iacute;me k metafoře s automobilem &ndash; nedod&aacute;v&aacute;me klientovi po č&aacute;stech precizně sestrojen&yacute; volant, n&aacute;pravu, karoserii a tak d&aacute;le. Dostane od n&aacute;s rovnou koloběžku, kter&aacute; ho doprav&iacute; z bodu A do bodu B. V tu chv&iacute;li může aplikaci vz&iacute;t a ověřit si jej&iacute; z&aacute;kladn&iacute; funkce v praxi se z&aacute;kazn&iacute;ky.</p>
<p><strong>Agiln&iacute; v&yacute;voj poč&iacute;t&aacute; s t&iacute;m, že se během projektu budou d&iacute;t změny,</strong> takže když se s klienty bav&iacute;me o ceně a jej&iacute;m zafixov&aacute;n&iacute;, doch&aacute;z&iacute;me k tomu, že je pro obě strany lep&scaron;&iacute; m&iacute;t <strong>flexibiln&iacute; budget.</strong> V&yacute;voj&aacute;ř pak nem&aacute; sv&aacute;zan&eacute; ruce, když ze strany klienta přijdou v průběhu v&yacute;voje nov&eacute; požadavky, a kromě toho dok&aacute;že pružně zakomponovat novinky z technologick&eacute;ho pokroku.</p>
<p><img src="https://api.koala42.com/assets/895a5aa7-c3a2-460d-937f-d1129c6016ec?width=1667&amp;height=1042" alt="Agiln&iacute; V&yacute;voj" /></p>
<h5>Design v pojet&iacute; Koaly</h5>
<p>Na zač&aacute;tku spolupr&aacute;ce si nejdř&iacute;v ze v&scaron;eho s klientem <strong>potvrd&iacute;me koncept aplikace</strong> a zjist&iacute;me od něj maximum informac&iacute; o tom, jak&eacute; funkce od n&iacute; potřebuje. Během anal&yacute;zy se snaž&iacute;me co nejl&eacute;pe pochopit, jak funguje klientův produkt (nebo procesy, pokud jde o intern&iacute; aplikaci), na co klade největ&scaron;&iacute; důraz a <strong>jak může aplikace podpořit jeho &bdquo;edge&ldquo;,</strong> tedy konkurenčn&iacute; v&yacute;hodu oproti ostatn&iacute;m v oboru.</p>
<p>Už při v&yacute;voji koloběžky db&aacute;me na to, aby design byl na dobr&eacute; &uacute;rovni a aby byl funkčn&iacute;. V t&eacute;to f&aacute;zi m&aacute; hlavn&iacute; slovo UX design&eacute;r, kter&yacute; m&aacute; za &uacute;kol <strong>nastavit logiku aplikace z pohledu uživatele</strong>&ndash; aby orientace v jej&iacute;m rozhran&iacute; byla snadn&aacute; a průchod jej&iacute;mi č&aacute;stmi logick&yacute;.&nbsp;</p>
<p>Domluvenou představu o aplikaci co nejdř&iacute;ve přev&aacute;d&iacute;me do podoby UX prototypu, kter&yacute; si klient může <strong>proklikat a prohl&eacute;dnout do posledn&iacute;ho detailu.</strong> Je lep&scaron;&iacute; si aplikaci co maxim&aacute;lně odladit dř&iacute;v, než se začne programovat. Později během samotn&eacute;ho v&yacute;voje už jsou vět&scaron;&iacute; z&aacute;sahy do produktu n&aacute;ročněj&scaron;&iacute; a zbytečně draž&scaron;&iacute;.&nbsp;</p>
<h5>Postupn&eacute; iterov&aacute;n&iacute; aplikace</h5>
<p>Od chv&iacute;le, kdy si s klientem odsouhlas&iacute;me UX prototyp a shodneme se, kter&eacute; funkce by z&aacute;sadně měly b&yacute;t souč&aacute;st&iacute; aplikace, se rozj&iacute;žd&iacute; samotn&yacute; agiln&iacute; v&yacute;voj. Na zač&aacute;tku 14denn&iacute;ho sprintu si s klientem vždy řekneme, co je re&aacute;ln&eacute; stihnout, a <strong>na konci sprintu mu odevzd&aacute;v&aacute;me funkčn&iacute; demo</strong> v takzvan&eacute; dev verzi na testovac&iacute;m serveru.</p>
<p>Jak už bylo řečeno, na&scaron;&iacute;m &uacute;kolem je klientovi co nejdř&iacute;ve dodat poj&iacute;zdn&yacute; model &ndash; koloběžku, kter&eacute; se ř&iacute;k&aacute; <strong>MVP (minimal viable product)</strong>. Po MVP n&aacute;sleduje kolo, kter&eacute; toho um&iacute; o něco v&iacute;c, pak motorka a nakonec ono Ferrari, kter&eacute; dost možn&aacute; bylo v pl&aacute;nu od sam&eacute;ho zač&aacute;tku, ale mohlo se k němu taky dospět až cestou.</p>
<p>Někdy se může st&aacute;t, že po kole přijde loď, protože si klient během v&yacute;voje aplikace uvědomil, že jeho podnik&aacute;n&iacute; je o něčem trochu jin&eacute;m. D&iacute;ky tomu, jakou flexibilitu agiln&iacute; v&yacute;voj umožňuje, to ale nemus&iacute; b&yacute;t takov&yacute; probl&eacute;m.</p>
<h5>Db&aacute;me na zastupitelnost</h5>
<p>Podle n&aacute;ročnosti aplikace na programov&aacute;n&iacute; př&iacute;padně jeden až tři z celkov&eacute;ho t&yacute;mu 13 zku&scaron;en&yacute;ch v&yacute;voj&aacute;řů. M&aacute;me v t&yacute;mu lidi s &scaron;irok&yacute;m z&aacute;běrem v technologi&iacute;ch a programovac&iacute;ch jazyc&iacute;ch, ale z&aacute;roveň <strong>drž&iacute;me kolektivn&iacute; know-how projektu, </strong>abychom zaručili zastupitelnost a aby se sprinty v př&iacute;padě nemoci nebo n&aacute;hl&eacute;ho v&yacute;padku lid&iacute; nezadrh&aacute;valy. P&iacute;&scaron;eme k&oacute;d i dokumentaci tak, aby mohl kdokoli do projektu <strong>naskočit, rychle se zorientovat a nav&aacute;zat na kolegovu pr&aacute;ci.</strong></p>
<h5>Komunikace mezi v&yacute;voj&aacute;řem a klientem</h5>
<p>Je pro n&aacute;s &uacute;plně běžn&eacute; se s klientem synchronizovat denně nebo p&aacute;rkr&aacute;t do t&yacute;dne. Jsme dostupn&iacute; na telefonu, na e-mailu, nebo chatovac&iacute;ch n&aacute;stroj&iacute;ch. V&scaron;echny požadavky sepisujeme do backlogu, kter&yacute; v každ&eacute;m dan&eacute;m okamžiku přesně odr&aacute;ž&iacute; současn&yacute; stav aplikace. M&aacute;me potom <strong>pečliv&yacute; z&aacute;znam o tom, kde zrovna ve v&yacute;voji jsme a na čem jsme</strong> se s klientem domluvili.</p>
<p>Každ&yacute; projekt postupně roste. Koloběžka na sebe nabaluje dal&scaron;&iacute; a dal&scaron;&iacute; funkce a zakomponovat je b&yacute;v&aacute; těž&scaron;&iacute; než na zač&aacute;tku, protože už se jedn&aacute; o <strong>změny v mnohem komplexněj&scaron;&iacute;m celku.</strong> I přesun tlač&iacute;tka na jin&eacute; m&iacute;sto může trvat půl dne, protože k tomu nestač&iacute; Ctrl+X a Ctrl+V.</p>
<p><img src="https://api.koala42.com/assets/246b9e0d-0233-4ad3-a1d7-c95535cebaa4?width=1667&amp;height=1043" alt="Vyvoj Aplikace" /></p>
<h4><img src="https://api.koala42.com/assets/5cd43ab3-9543-4182-9c77-26923757b8a9?width=32&amp;height=25" alt="quotes" /></h4>
<h4>V&yacute;voj&aacute;ř mus&iacute; nejdř&iacute;v zjistit, co v&scaron;echno změna ovlivn&iacute;, mus&iacute; ji napl&aacute;novat, prov&eacute;st a otestovat. Na backendu se může snadno st&aacute;t, že se i men&scaron;&iacute; změna nečekan&yacute;m způsobem projev&iacute; v &uacute;plně jin&eacute; č&aacute;sti aplikace.</h4>
<p>O časov&eacute; n&aacute;ročnosti ale s klientem otevřeně mluv&iacute;me a na konci sprintu ukazujeme, kolik hodin se str&aacute;vilo na kter&eacute;m &uacute;kolu, abychom př&iacute;padně mohli upravit priority.</p>
<h5>Testov&aacute;n&iacute;, opom&iacute;jen&aacute; č&aacute;st v&yacute;voje</h5>
<p>Pokud je na testov&aacute;n&iacute; vyčleněn&aacute; jenom mal&aacute; č&aacute;st rozpočtu, nedaj&iacute; se naskriptovat a prov&eacute;st <strong>opravdu hloubkov&eacute;, automatizovan&eacute; testy.</strong> Manu&aacute;ln&iacute; testy jdou bohužel vždy jen po povrchu a nepokryj&iacute; každou představitelnou kombinaci kroků, kterou může později uživatel v re&aacute;lu prov&eacute;st.&nbsp;</p>
<p><img src="https://api.koala42.com/assets/7dbcc979-313d-4dc5-bbd5-12825c0448d8?width=1667&amp;height=1042" alt="Vyvoj Aplikace Koala" /></p>
<p>Může se potom st&aacute;t, že aplikace se zasekne a spadne zrovna ve chv&iacute;li, kdy si ji prohl&iacute;ž&iacute; CEO &ndash; kdy jindy, že? &ndash; a probl&eacute;m je na světě. <strong>Automatizace je v testov&aacute;n&iacute; vždy v&yacute;hodn&aacute;. </strong>Je důležit&aacute; kvůli zachycen&iacute; př&iacute;padn&eacute; regrese &ndash; tedy toho, že po nov&eacute; změně přestane fungovat k&oacute;d v dř&iacute;ve napsan&yacute;ch (a otestovan&yacute;ch) č&aacute;stech aplikace. Automatizace tedy &scaron;etř&iacute; obrovsk&eacute; množstv&iacute; času v&yacute;voj&aacute;řům i testerům a my ji rozhodně považujeme za <strong>důležit&yacute; krok směrem ke &scaron;pičkov&eacute; v&yacute;sledn&eacute; kvalitě.</strong></p>
<h5>Vyd&aacute;n&iacute;m př&iacute;běh nekonč&iacute;</h5>
<p>Když je v&scaron;e v poř&aacute;dku otestov&aacute;no a schv&aacute;leno, můžeme prov&eacute;st release &ndash; aplikaci vydat. Vyd&aacute;n&iacute; znamen&aacute; přesun k&oacute;du aplikace na produkčn&iacute; server a publikaci na webu, př&iacute;padně v App Store (iOS) a/nebo Google Play (Android). Ať už je to koloběžka, kolo, nebo motorka, nen&iacute; to tak, že bychom si opr&aacute;&scaron;ili ruce, vystavili fakturu a &scaron;li od toho. Opravujeme bugy, kter&eacute; se mohou projevit až po nějak&eacute; době, a <strong>optimalizujeme v n&aacute;vaznosti na aktualizace operačn&iacute;ch syst&eacute;mů.</strong></p>
<h4><img src="https://api.koala42.com/assets/5cd43ab3-9543-4182-9c77-26923757b8a9?width=32&amp;height=25" alt="quotes" /></h4>
<h4>Přeci jen jsme postavili funkčn&iacute; n&aacute;stroj a je na n&aacute;s, abychom ho udrželi při životě.</h4>
<p>Kromě samozřejm&yacute;ch oprav klienta r&aacute;di upozorn&iacute;me, když se objev&iacute; nov&aacute; technologie, kter&aacute; by pro jeho projekt mohla m&iacute;t nějakou zaj&iacute;mavou přidanou hodnotu, takže se potom spolupr&aacute;ce může rozv&iacute;jet roky. <strong>Z&aacute;lež&iacute; n&aacute;m na dlouhodob&yacute;ch vztaz&iacute;ch</strong> a kvalita u n&aacute;s pokažd&eacute; zv&iacute;těz&iacute; nad kvantitou. A proto m&aacute;me projektů č&iacute;m d&aacute;l v&iacute;c.</p>

<h4>At the onset of each project, our clients ask questions of Life, the Universe, and Everything: How does app development work? How will we communicate? What kind of budget should we set aside? This article focuses on the first two questions, and the last will be tackled in a separate piece.</h4>
<p>It&rsquo;s not a strict rule for us to only accept projects where we can build an application from the ground up. Sometimes a company approaches us with an app that is already underway, asking us to finish it. We&rsquo;re not terribly opposed to the idea &ndash; <strong>we understand that the client needs to carry on with the tech stack the app was designed in </strong>and cannot afford to throw the money they&rsquo;ve already invested out the window. So we often meet the client halfway and take over for the missing part of the process. But for the purposes of this article, <strong>we&rsquo;re going to take a look at app development from start to finish</strong>, and we&rsquo;ll go through the following topics:</p>
<ul>
<li><strong>The problem with waterfall methodology</strong></li>
<li><strong>Why agile development works better</strong></li>
<li><strong>Koala&rsquo;s approach to app design</strong></li>
<li><strong>The road to the MVP and beyond</strong></li>
<li><strong>How we maintain collective know-how</strong></li>
<li><strong>Communication with the client</strong></li>
<li><strong>Testing deserves proper attention</strong></li>
<li><strong>Releasing the app is not the end</strong></li>
</ul>
<h5>The problem with the waterfall methodology</h5>
<p>Some clients (most, in fact) still like to approach a software company with a project, announce a budget and ask for the date of delivery. They are usually very keen to put a definite ceiling on the final price.&nbsp;</p>
<p>What we like to explain to them, however, is that if we go with the software development process called the &ldquo;waterfall model&rdquo;, it will take months before they can lay their hands on a functional version of the product. <strong>In the waterfall methodology, an app is developed very meticulously stage after stage </strong>(analysis, design, development, testing), and each new stage is approached only when the previous one is considered complete. Also, the ambition of the design phase is to plan perfectly and account for all possible use cases, problems and pitfalls in advance.</p>
<h4><img src="https://api.koala42.com/assets/5cd43ab3-9543-4182-9c77-26923757b8a9?width=32&amp;height=25" alt="quotes" /></h4>
<h4>App development is sometimes compared to building a car &ndash; and in the waterfall methodology, the developer is designing a Ferrari right from the get-go. For months, the client only looks at the app&rsquo;s blueprints, and an actual test drive becomes possible towards the end of the project.</h4>
<p><img src="https://api.koala42.com/assets/b2de7fa9-60d3-4d85-8edd-2a9d593d8f97?width=1024&amp;height=410" alt="agile development" /></p>
<h5>Why agile development works better</h5>
<p>Agile development, on the other hand, is an iterative approach that moves forward in shorter leaps &ndash; <strong>sprints</strong>. Each sprint is a development cycle in itself, from analysis to testing, and it sets specific tasks and goals which are revised at the end (in 14 days). In an agile model, it&rsquo;s impossible to say whether an app will be finished in three months or six. <strong>The client, however, gets a report at the end of every sprint</strong>, sees how development has progressed exactly, and if necessary, <strong>can adjust priorities or requirements.</strong></p>
<p>Going back to the car metaphor, we don&rsquo;t deliver separate parts one by one &ndash; the steering wheel, chassis, tires and car body. We give the client a scooter that can get them from point A to point B, i.e. a functional version of the product they can test with customers, and then develop it into more advanced vehicles.</p>
<p><strong>The agile model accepts that project change is inevitable</strong>, so when we discuss money matters with the client, we generally agree that a <strong>flexible budget </strong>is good for both sides. The developer can then respond to change requests without hands tied, and even incorporate evolving new technology trends in their work.</p>
<p><img src="https://api.koala42.com/assets/b89718ce-ab8e-4717-93e2-451e6df5a420?width=1024&amp;height=640" alt="waterfall vs agile" /></p>
<h5>Koala&rsquo;s approach to app design</h5>
<p>At the beginning of a project, the first order of business is to <strong>confirm the application&rsquo;s concept</strong> and get as much information as we can about the functions it needs. The goal of the analysis stage is to understand how the client&rsquo;s product works (or their processes, if the app is meant for internal use), what needs to be the core functionality and <strong>how the app can support the client&rsquo;s &ldquo;edge&rdquo;</strong> over competitors.</p>
<p>As far as design goes, we pay extra attention to function already in the &ldquo;scooter&rdquo; stage. It&rsquo;s our <strong>UX designer&rsquo;s job to look at the logic of the app from the user&rsquo;s perspective</strong> and build the experience with the interface in a way that results in a seamless journey.</p>
<p>When we settle on app design with the client, we transform it into a 1:1 visual representation &ndash; <strong>a UX prototype </strong>&ndash; which the client can click through, check all details and give feedback. It&rsquo;s better to work out most features and intricacies at this stage, before we jump into programming. Large adjustments made later are tricky &ndash; not impossible, just more expensive and time-consuming.</p>
<h5>The road to the MVP and beyond</h5>
<p>Once the app is designed and confirmed, development starts leaping forward in sprints. At the beginning of each 14-day cycle we agree on tasks we are able to deliver within the timeframe, and a<strong>t the end the client gets a functional demo on our testing server.</strong></p>
<p>As mentioned above, our aim is to deliver the first functional version of the app &ndash; the MVP <strong>(minimal viable product) </strong>&ndash; as soon as possible. This &ldquo;scooter&rdquo; is then replaced by a bicycle with more functions and capabilities, after that a motorbike and finally the Ferrari, which may have been planned from the start, but it might as well be the product of dynamic collaboration.</p>
<p>Sometimes instead of a car we end up with a boat, because the client realizes during development that they in fact need the app to be something slightly different. But that&rsquo;s okay. This is exactly what agile development allows for.</p>
<h5>How we maintain collective know-how</h5>
<p>Depending on the complexity of the project, we dedicate 1&ndash;3 programmers from our current team of thirteen. All of our people combined have extensive experience with technologies and programming languages, but <strong>we also keep robust collective know-how project by project</strong>, so that developers can step in for one another and sprint results are not threatened by illness or days off. We write our documentation in a way that <strong>allows for anyone to pick up where a colleague left off.</strong></p>
<h5>Communication with the client</h5>
<p>Koala normally keeps in touch with clients on a daily basis or a couple of times a week. We can be reached on the phone, via messaging apps or by email. <strong>All requests are recorded in a detailed backlog that reflects the current status of the project. </strong>This helps us keep a track of all things agreed between us and the client.</p>
<p>Naturally, as the project grows and its functionality expands, implementing new features gets more complicated. Every change is made to a larger whole. Even seemingly simple things like moving a button to another place on the screen can take several hours, because it&rsquo;s not a matter of cut-and-paste. <strong>The developer first needs to determine what parts of the back-end code will be affected by this change</strong>, then he needs to plan, execute and test. Sometimes the modification will cause wonky problems in a completely unrelated part of the app.</p>
<p><img src="https://api.koala42.com/assets/21e2c4fd-9790-4e73-94f5-fac4d2f3455e?width=1024&amp;height=641" alt="development teams scheme" /></p>
<h4><img src="https://api.koala42.com/assets/5cd43ab3-9543-4182-9c77-26923757b8a9?width=32&amp;height=25" alt="quotes" /></h4>
<h4>No matter what happens, we are always transparent about time spent on tasks, and we adjust task priorities according to the client&rsquo;s preference.</h4>
<h5>Testing deserves proper attention</h5>
<p>If the budget is limited when it comes to testing, we are unable to write <strong>scripts for thorough, automated tests.</strong> Manual tests unfortunately cannot scratch much more than the surface of the app and simulate any possible combination of actions that a user could make in the app.</p>
<p><img src="https://api.koala42.com/assets/49d70351-0865-4ea9-9478-f2d1c456e248?width=1024&amp;height=640" alt="app testing scheme KOALA42" /></p>
<p>It can then happen (and it does &ndash; Murphy&rsquo;s law) that the app crashes in the precise moment the CEO is looking at it. <strong>Performing automated tests is always a plus.</strong> It&rsquo;s important also with respect to regression testing, i.e. testing that detects problems in previously developed and tested parts of the software, after changes. Automation saves programmers and testers precious time and we definitely consider it a<strong> vital part of being able to deliver a top-quality product.</strong></p>
<h5>Releasing the app is not the end</h5>
<p>After the app has been successfully tested and approved by the client, it is released &ndash; deployed to our production server and published as a web application or on mobile stores &ndash; App Store (iOS) and/or Google Play (Android). &nbsp; Whether it&rsquo;s a scooter, bike or car, we&rsquo;re not done with it the moment it&rsquo;s released. <strong>We keep monitoring, fixing bugs, and optimizing in the wake of operation system updates.</strong></p>
<h4><img src="https://api.koala42.com/assets/5cd43ab3-9543-4182-9c77-26923757b8a9?width=32&amp;height=25" alt="quotes" /></h4>
<h4>After all, it&rsquo;s a tool we brought to life, and it&rsquo;s our responsibility to keep it running.</h4>
<p>Apart from fixes that go without saying, we&rsquo;re also happy to bring it to the client&rsquo;s attention when technology progress presents a fresh opportunity or holds potential added value. Cooperation with clients can go on for years. <strong>Building long-lasting relationships is important to us</strong>, and quality always wins over quantity. That&rsquo;s probably why the number of our projects keeps growing.</p>

Máte v hlavě nápad na projekt?

Přečtěte si náš blog

Kontakt

Jan Jelínek

Stále rosteme,

Praha

Zlín

Máte v hlavě nápad na další projekt? Pojďme ho probrat.