Heeft u een vraag, opmerking of wilt u meer informatie over onze diensten vult u dan onderstaand formulier in of neem telefonisch contact met ons op.
AppBakkers (Zwolle)
Aagje Dekenstraat 51
8023 BZ Zwolle
+31 (0)38 303 2600
support@appbakkers.nl
AppBakkers (Amsterdam)
Tt. Vasumweg 122
1033 SH Amsterdam
+31 (0)38 303 2600
support@appbakkers.nl
De software die door ons wordt ontwikkeld in opdracht van de klant wordt eigendom van de klant. De overdracht van het intellectueel eigendom moet wettelijk gezien worden gedaan door middel van een schriftelijke verklaring. Wij werken met een standaard overeenkomst die aan het eind van het project door beide partijen wordt ondertekend.
Overdracht van eigendom van de code betekent in de praktijk iets anders dan dat de code nooit meer gebruikt mag worden. Een voorbeeld zal dit duidelijk maken: als we voor een specifieke applicatie een login functie maken kunnen we deze code in een andere applicatie hergebruiken. Als in een overeenkomst zou staan dat we deze code nooit meer mogen gebruiken voor een andere klant wordt het voor ons op een bepaald moment onmogelijk om code te schrijven voor een login functie. Om die reden wordt het eigendom van de gehele code overgedragen, met de nadere bepaling dat delen van de code hergebruikt kunnen worden in andere applicaties.
Bij veel software bedrijven zult u horen dat ze ‘agile’ werken of via ‘scrum’. Bij Appbakkers zetten we deze projectaanpak ook in, maar niet als doel. We kijken per project en per opdrachtgever welke aanpak het beste werkt. In de praktijk blijkt vaak dat het werken in korte perioden (zogenaamde sprints) met daarna een periode van testen van wat er gemaakt is de beste resultaten oplevert. Daarom werken we vaak in een periode van 2 weken ontwikkelen, 1 week testen. Op deze manier kan tijdens de ontwikkeling veel controle worden uitgeoefend op het eindresultaat en kan tijdig worden bijgestuurd.
We brengen elk project onder in onze project management software. Het totale project wordt opgedeeld in zogenaamde use cases en per use case wordt een urenschatting aangegeven. Vervolgens wordt een sprint samengesteld uit de use cases en wordt in de software de voortgang bijgehouden. Zo is op elk moment duidelijk hoe het staat met de voortgang van het project.
Op deze vraag kan op voorhand geen antwoord worden gegeven. Het is net als met auto’s: je kunt een auto kopen voor 5.000 euro, maar ook voor 500.000 euro. De kosten van een app hangen sterk samen met de volgende aspecten:
Ja, bij Appbakkers werken we met een aantal tools om het gebruik van de apps die we voor klanten hebben ontwikkeld inzichtelijk te maken. In de eerste plaats delen we download statistieken van de apps met onze klanten. Daarnaast voegen we in veel gevallen (uiteraard in overleg met de opdrachtgever) meetsoftware toe aan de app. Wij doen dit met behulp van Google Firebase, dat vergelijkbaar is met Google Analytics dat veel bedrijven inzetten voor het meten van klikgedrag op hun website. Google Firebase doet hetzelfde als Google Analytics, maar dan voor apps.
Als klanten beacons willen inzetten in hun app dan verzamelen we via ons eigen beacon platform statistieken over de interactie tussen de app en de beacons. Hierdoor ontstaat een goed beeld van hoe gebruikers reageren op berichten die we sturen als ze in de buurt van een beacon komen of op andere triggers die geactiveerd worden als app gebruikers in de buurt van de beacons komen. Ditzelfde doen we via ons platform op basis van geofencing.
Een webapp is een webapplicatie die je kunt gebruiken door een website adres in te voeren in je browser. Vervolgens zou je de URL kunnen bookmarken op je telefoon, zodat je de website snel weer kan openen. Een webapp kan niet worden gedownload uit de appstores. Dit kan een voordeel zijn, omdat vooral Apple tegenwoordig strengere eisen stelt aan de functionaliteiten van de apps die het toelaat in de appstore. Vooral eenvoudige apps kunnen daarom beter als webapp worden ontwikkelt. Verder is het voordeel van een webapp dat de ontwikkeling goedkoper is. Nadelen zijn dat hardwarematige functies van de smartphone (zoals de camera) vaak niet gebruikt kunnen worden met een webapp, dat er altijd een internetverbinding nodig is om de app te kunnen gebruiken en dat er geen data op de telefoon wordt opgeslagen
Een native app is een app die is geschreven in de programmeertaal die specifiek bedoeld is voor Android of iOS. De app ‘voelt’ daarmee vaak soepel aan, alle functies van de smartphone kunnen worden gebruikt en de app kan worden gedistribueerd via de appstores. De apps kunnen in de regel ook zonder internetconnectie worden gebruikt. Nadelen zijn dat de er voor twee (of drie als Windows Phone wordt meegenomen) platformen ontwikkeld moet worden, waardoor de kosten hoger zijn dan bij een webapp. Een ander nadeel is dat bij een update van de software de app opnieuw aangeboden moet worden aan de appstores. Tenslotte is een nadeel van native apps dat Apple hogere eisen stelt aan de functionaliteit, waardoor eenvoudige apps met beperkte functionaliteit soms geweigerd worden door Apple.
Onder hybride app kan twee dingen worden verstaan: een webapp die zich door middel van een zogenaamde ‘wrapper’ gedraagt als een native app, terwijl het in feite niks anders is dan een webapp waar een schil omheen zit. Het voordeel is dat de app op deze manier via de appstore kan worden gedistribueerd, alhoewel Apple dergelijke apps vaak weigert op te nemen.
Tegenwoordig wordt onder hybride apps ook wel verstaan een app die gebouwd is via een software tool, waarbij de ontwikkelde software code op zowel iOS als Android gebruikt kan worden. Een voorbeeld van een dergelijke tool is Xamarin. Het voordeel van ontwikkelen met Xamarin is dat veel van de code slechts 1 keer geschreven hoeft te worden en de kosten voor ontwikkelen van de app voor Android en iOS lager uitvallen.
Regelmatig worden benaderd door ondernemers met een goed app idee, die vragen of wij de app kostenloos of tegen geringe investering willen maken in ruil voor de toekomstige opbrengsten van de app of applicatie. Wij zijn heel kieskeurig als het gaat om deze vorm van beloning. Ten eerste vinden wij dat de ondernemer zelf in staat zou moeten zijn om het te investeren bedrag bij elkaar te brengen. In de tweede plaats wordt het risico in dit soort constructies vaak teveel bij de app-bouwer neergelegd. Maar als we zelf 100% overtuigd zijn dat de app voorziet in een echte behoefte en het businessmodel is ook goed dan staan we open voor een alternatieve vorm van financiering van onze ontwikkeluren.
We hebben bij Appbakkers geen specialisten op het gebied van het verkopen van apps. Wel hebben we gemerkt dat het succes van een app voor een groot deel wordt bepaald door marketing rond de app. Wij werken daarom samen met onze partner Het Gilde uit Deventer, die onze klanten kan helpen de app onder de aandacht te brengen bij de doelgroep.
Wij kunnen voor u ook het ontwerp van de app maken. We hebben hiervoor onze eigen (freelance) ontwerpster waarmee we al veel verschillende projecten hebben uitgevoerd. Daarnaast werken we samen met een paar vaste ontwerpbureaus. Het grote voordeel van het werken met vaste partners is dat zij onze werkwijze begrijpen, de ontwerpen in een formaat aanleveren dat we direct kunnen omzetten naar app-schermen en dat de ontwerpers weten welke ontwerpkeuzes leiden tot fors hogere kosten. Dit maakt het eenvoudiger om samen met de opdrachtgever een juiste balans te vinden tussen fraaie grafische features en het beschikbare budget voor het project.
Als u werkt met een vaste partner voor ontwerp of u heeft zelf ontwerpers in dienst kunnen we ook op basis van door u aangeleverd ontwerp de applicatie bouwen.
Ja, wij maken ook afspraken met klanten voor het onderhouden van de apps. Onderhoud is noodzakelijk omdat de besturingssystemen van smartphones regelmatig worden geüpdate. Om ervoor te zorgen dat de apps ook na update van Android of iOS nog functioneren voeren we onderhoud uit. Voor het onderhoud maken we in een aparte overeenkomst afspraken met onze klanten. In de regel zijn de kosten een vast percentage van de ontwikkelkosten.
Nee, in principe werken we niet op basis van fixed price. We zijn er door ervaring van overtuigd geraakt dat een fixed price afspraak voor zowel onze klanten als ons zelf niet leidt tot het gewenste resultaat. Voor de klant betekent een fixed price afspraak namelijk dat de scope en alle functionaliteit van het eindproduct duidelijk moeten zijn en dat elke wijziging van de scope direct leidt tot nieuwe prijsafspraken. Klanten vinden deze procedure vaak niet prettig. Voor Appbakkers betekent een fixed price afspraak een verhoogd risico, waardoor we genoodzaakt zijn een risicotoeslag te berekenen en scherp gaan controleren of er geen nieuwe functionaliteit wordt toegevoegd tijdens het project.
Hoe werken wel wel? We maken voor het project een open calculatie, waarin van te voren duidelijk is wat het maken van de functionaliteit kost aan uren en we maken een afspraak hoe we omgaan met de uren die boven de calculatie uitkomen. Dit leidt in bijna alle gevallen tot een tevreden opdrachtgever, succesvolle projecten en een goede verstandhouding tussen Appbakkers en opdrachtgever.
