Wat bepaalt de prijs van een app?
Eén vraag verschuift het bedrag meer dan alle andere samen: moet er iets buiten het toestel gebeuren? Een app die alles lokaal doet en synchroniseert via het iCloud-account van de gebruiker heeft geen server, geen inlog, geen wachtwoordherstel en geen maandrekening. Zodra mensen moeten inloggen, elkaars gegevens zien of data uit jouw systemen halen, koop je er een tweede product bij dat ook gebouwd, beveiligd en onderhouden moet worden.
Daarna pas de rest:
- Aantal schermen, niet als telling maar omdat elk scherm ook een lege, een ladende, een mislukte en een offline versie heeft. Daar zit het werk.
- Betalingen: een eenmalige aankoop is iets anders dan abonnementen met proefperiodes, herstel van aankopen en een status die klopt op elk toestel van dezelfde gebruiker.
- Koppelingen met systemen die jij niet beheert. De kwaliteit van die API bepaalt je planning, en die ken je pas als je erin zit.
- Beheer: moet iemand content kunnen wijzigen, dan bouw je er een tweede applicatie bij.
- Ontwerp: bouwen met de componenten van het systeem gaat sneller en voelt vertrouwder dan een volledig eigen vormtaal.
Waarom lopen offertes voor hetzelfde idee zo ver uiteen?
Omdat een offerte een gok is op wat jij bedoelde. Twee partijen die precies hetzelfde gesprek voerden kunnen ver uit elkaar liggen zonder dat een van beide onzin verkoopt: de een rekende de nette randen mee, de ander niet.
Vraag daarom niet wat erin zit, maar wat eruit is gelaten. Zit foutafhandeling en offlinegedrag erin? Het verwijderen van een account, wat Apple verlangt zodra je accounts hebt? De privacylabels, teksten en screenshots in App Store Connect, het indienen zelf, en een ronde om reviewfeedback te verwerken? Een lage prijs is meestal dezelfde app minus die punten. Ze verdwijnen niet, ze verhuizen naar een meerwerkfactuur.
De tweede reden is de techniekkeuze. Native of cross-platform verplaatst het bedrag harder dan welke feature ook; die afweging heb ik apart uitgeschreven.
Bureau, offshore-team of één maker die alles doet?
Bij een bureau koop je continuïteit. Er is altijd iemand bereikbaar en als er iemand uitvalt gaat het door. Je betaalt daarvoor de laag ertussen, en je weet zelden wie er daadwerkelijk typt: het gesprek voer je met de senior, de code komt vaak van iemand anders.
Offshore is per uur echt goedkoper. Je betaalt dat terug in specificatiewerk, want alles wat jij niet opschrijft wordt geraden door iemand die jouw gebruikers niet kent, en dat merk je pas bij de oplevering. Heb je zelf iemand technisch in huis die dagelijks meekijkt, dan kan het prima uitpakken.
Bij één maker praat je met degene die bouwt. Er gaat niets verloren tussen wat je zegt en wat er gebeurt, beslissingen vallen dezelfde dag, en niemand heeft er belang bij de scope op te blazen. Het risico is even helder: het is één persoon. Dat vang je niet op met vertrouwen maar met eigendom, en verderop staat hoe. Zo werk ik als freelancer.
Bij die derde variant is er nog iets dat meeweegt en dat in offertes zelden terugkomt: waar die maker zit. Ik werk vanuit Delft, en wat nabijheid wel en niet waard is — plus wie er in werkelijkheid achter de meeste stadspagina's zit — staat op een app laten maken in Delft.
Wanneer je beter niet bij mij moet zijn
Ik bouw native voor de Apple-platforms. Is Android je eerste markt of even belangrijk, dan heb je daar een aparte build en meestal een tweede maker voor nodig. Dat kan, maar dan ben ik niet de eenvoudigste route.
Ook niet bij mij: projecten die vanaf de tweede maand met tien mensen parallel moeten lopen omdat de datum vaststaat. Werk dat één persoon doet gaat serieel. Dat is uitstekend voor een scherp afgebakende eerste versie en verkeerd voor een programma met tien werkstromen en een stuurgroep. Hetzelfde geldt voor het uitbreiden van een groot bestaand platform waar je een gespecialiseerd team op wilt zetten.
En zoek je vooral de laagste prijs, dan vind je die elders. Bij mij zit er geen laag tussen jou en degene die bouwt; wat dat in jouw geval betekent, hoor je pas als ik weet wat je wilt bouwen.
Hoe ziet 'van idee tot App Store' er in de praktijk uit?
- Scherpstellen. Wat de app doet en vooral wat hij niet doet. De kleinste versie die je aan een echte gebruiker durft te geven.
- Schermen schetsen. Een klikbaar model voordat er logica onder zit, want daar zijn wijzigingen nog gratis.
- Bouwen in rondes. Elke ronde iets werkends op jouw eigen toestel via TestFlight, zodat je stuurt op wat je vasthoudt in plaats van op een statusrapport.
- De randen. Offline, foutmeldingen, permissies voor microfoon of locatie, en de vraag waar de gegevens precies staan.
- Store-voorbereiding. Privacylabels, screenshots, teksten, abonnementen, en accountverwijdering als er accounts zijn.
- Indienen. Apple beoordeelt elke inzending. Een afwijzing is geen ramp maar wel een ronde, dus je wilt het in één keer goed hebben.
- De ronde erna. De eerste echte gebruikers laten zien welk scherm je verkeerd had begrepen. Plan daar ruimte voor in, niet budget dat al op is.
Wat kost de app nadat hij live staat?
Onderhoud bij apps is geen potje voor als er iets stukgaat, het is een abonnement op het platform. Elk najaar komt er een nieuwe versie van iOS en macOS waarin dingen verschuiven, en de regels van Apple bewegen mee: een update kan worden afgekeurd op een punt dat er bij de eerste indiening nog niet was. Een app die een jaar met rust wordt gelaten, ziet er een jaar later ook zo uit.
Daarnaast loopt het lidmaatschap van het Apple Developer Program per jaar door, en als er een server bij hoort, blijft die rekening komen of je nu doorontwikkelt of niet. De ondersteuning is het drukst in de eerste maanden na de lancering. Zet onderhoud dus als vaste regel in je begroting, niet als uitzondering.
Wat je zelf in handen moet houden
De angst achter de meeste vragen op deze pagina is niet de prijs, maar de bouwer die halverwege verdwijnt. Daar bestaat een verzekering voor en die kost je niets extra's, alleen dat je er aan het begin om vraagt.
- Het Apple Developer-account staat op naam van jouw onderneming en jij bent de accounthouder. De bouwer krijgt toegang, niet andersom.
- De code staat vanaf dag één in een repository die van jou is, niet pas bij oplevering.
- Accounts bij diensten die de app gebruikt staan op jouw naam en jouw betaalmiddel.
- Leg vast dat het resultaat van jou is en dat certificaten, sleutels en ontwerpbestanden meekomen.
Is dat geregeld, dan is het vertrek van je bouwer een vervelende maand en niet het einde van je product.
Waarom ik weet wat er na de oplevering gebeurt
Ik bouw niet alleen voor anderen, ik breng ook eigen apps uit. De rekening voor mijn eigen beslissingen komt dus bij mij terecht: abonnementen via StoreKit, synchronisatie via CloudKit, widgets en Live Activities, plus het volledige papierwerk richting de store.
Transcribier is spraakdictaat voor Mac, iPhone en iPad. Je spreekt en het typt, in elke app met een tekstveld, via een globale sneltoets op de Mac en een systeemtoetsenbord op iPhone en iPad. Transcriptie loopt over ElevenLabs Scribe in zestien talen, met de sleutel van de gebruiker zelf, zodat de audio naar zijn eigen account gaat en niet naar de mijne. Meer over Transcribier.
Best-I is Nederlandstalig en meet waar je energie blijft, op vier assen, met wekelijks één focus op basis van je laagste batterij en een versleuteld dagboek voor tekst, foto's, video en spraakmemo's. De sleutels blijven op het toestel en de synchronisatie loopt via het iCloud-account van de gebruiker. Meer over Best-I, mijn app voor je energiebalans.
Geen van beide staat vandaag in de App Store. Voor Transcribier is er een wachtlijst, Best-I komt binnenkort uit.