HelioPeak bouwen: lessen uit indie iOS-development

Een paar maanden van avonden en weekenden, zes talen, drie platformen, één ontwikkelaar. Dat is in één zin het verhaal achter HelioPeak. Dit artikel gaat over hoe dat verhaal er werkelijk uitzag in de praktijk: wat goed liep, wat moeilijk was, wat ik leerde over indie iOS-ontwikkeling in 2026, en welke kleine beslissingen onverwacht groot bleken.

Het is iets persoonlijker dan de andere artikels in deze reeks. Wie geen interesse heeft in de achterkant van een kleine app, zou dit kunnen overslaan. Wie wel: ik probeer eerlijk te zijn over wat een soloproject in deze tijd inhoudt, zonder de typische cliché's van "je moet alleen je passie volgen" of "het kost minder dan je denkt". Beide zijn meestal valse versimpelingen.

Het uitgangspunt

Ik ben geen Swift-ontwikkelaar van opleiding. Mijn achtergrond is IT, infrastructuur, systeemarchitectuur, niet mobile development. Ik had voor HelioPeak nooit een iOS-app ge

publiceerd. Mijn Apple Developer-account was van vroeger maar nooit voor publicatie gebruikt. Mijn Swift-ervaring beperkte zich tot een paar uur experimenteren met SwiftUI in 2024.

Toch wilde ik een specifieke iOS-app maken: een fatsoenlijke PVOutput-client voor mezelf. De bestaande apps deden niet exact wat ik wilde, en omdat ik genoeg technische achtergrond heb om ze niet onmogelijk te vinden, heb ik op een avond in januari 2026 besloten om er een te bouwen.

De redenering was simpel: de schaal is klein (één persoon zonne-energie volgen), de complexiteit lijkt beheersbaar (een dashboard, wat grafieken, wat configuratie), en ik heb AI-tooling beschikbaar die het Swift-leercurve-stuk kan helpen verzachten. Slechtste geval: ik leer iets nieuws en publiceer nooit een app. Beste geval: ik heb iets dat ik zelf graag gebruik.

De AI-assistentie

Hier komt de eerste oprechte zaak die ik wil zeggen: zonder Claude (de AI-tool die ik gebruik) had dit project waarschijnlijk niet bestaan. Niet omdat de AI alles voor me deed, maar omdat hij de leerdrempel laag genoeg maakte om door te zetten op avonden waarop ik na een dag werk geen energie meer had om een Swift-tutorial te lezen.

Wat de AI in de praktijk doet:

• Boilerplate genereren. SwiftUI heeft veel terugkerende patronen (NavigationStack, sheet, gestureRecognizer). Een AI die deze patronen kent, scheelt veel typewerk.
• Vertalingen suggereren tussen frameworks. "Hoe doe je een blur achter dit element?" of "Wat is het modern alternatief voor deze deprecated API?" zijn vragen waar de AI vaak meteen het juiste antwoord op heeft, sneller dan Stack Overflow.
• Architectuur-overwegingen voorstellen. Wanneer je niet zeker bent of een feature thuishoort in een view-model of in een aparte service, kan een AI je daarover laten reflecteren en de voor-en-nadelen scherp formuleren.
• Foutmeldingen ontleden. SwiftUI's error messages zijn berucht slecht. Een AI die de stack-trace kan lezen en de werkelijke fout uitleggen, scheelt uren.

Wat de AI niet doet:

• Architectuur-beslissingen voor mij maken. Dat blijft mijn werk. De AI suggereert opties; ik kies welke aansluit bij waar ik naartoe wil.
• Bugs vinden in mijn eigen code. Een AI is niet beter dan ik in het lezen van mijn eigen logica. Hij kan helpen, maar de uiteindelijke debug-sessie is altijd manueel.
• De ervaring van real-device-testen vervangen. Wat goed lijkt op een simulator op een Mac, faalt soms op een echte iPhone 13 mini. Dat zie je alleen met de telefoon in de hand.
• Productrichting bepalen. Wat HelioPeak wel of niet zou moeten doen, welke prijsstelling, welke prioriteiten in features, dat zijn beslissingen waar geen AI je in kan vervangen.

Dit is hopelijk geen verrassende uitspraak, maar ik denk dat het belangrijk is om eerlijk over zijn. De AI heeft mijn productiviteit waarschijnlijk verdubbeld of verdriedubbeld. Hij heeft mijn werk niet vervangen.

Wat ik onderschatte in de productieplanning

Dingen die ik fundamenteel verkeerd inschatte qua tijd:

Internationalisering. Ik heb HelioPeak van begin af aan in zes talen ontworpen, omdat ik wist dat ik de Belgische, Nederlandse, Franse, Duitse, Italiaanse en Spaanse markten wilde aanspreken. Dit is een fundamenteel correcte beslissing geweest qua product (de meertaligheid is een van mijn duidelijkste differentiators). Maar de operationele kost ervan onderschatte ik enorm.

Elke nieuwe UI-string die ik schrijf moet door zes vertalingen. Elke kleine UI-aanpassing kan een vertaling breken die te lang wordt voor de knop. Elk nieuw scherm vereist een translator-review. Dit is geen één-keer-doen-en-klaar; het is een doorlopende last die met elke release groeit. Ik werk eraan om dit beter te industrialiseren, maar ik begin nu pas te begrijpen hoeveel werk multilingue dev werkelijk is.

Apple's app store-proces. De eerste indiening van HelioPeak werd geweigerd door een developer-review die ik niet had verwacht. De review-feedback was vrij specifiek en oplosbaar, maar het hele proces (build, indienen, wachten, weigering, fix, opnieuw indienen, wachten, goedkeuring) kostte twee weken. Dat is twee weken extra in elke release-cyclus die ik niet vooraf inplanned. Voor de eerste release was dat een schok; voor latere releases heb ik mijn timing meer gekalibreerd.

Privacy compliance en privacy nutrition labels. Apple's vereisten voor privacybeleid, App Tracking Transparency, privacy nutrition labels, en aanverwante zaken zijn allemaal documenten en formulieren die op het oog klein lijken maar uren werk vragen om correct in te vullen. Voor wie eerlijk en transparant wil zijn over wat de app doet, is dit goed gebruikte tijd, maar het is wel tijd die in geen enkele "indie dev tutorial" wordt vermeld.

Marketing en discovery. Een goede app maken is één ding. Mensen vinden die hem willen gebruiken, is een heel ander ding. Dit is een aspect dat ik nog steeds aan het leren ben, en waar ik veel te weinig tijd voor heb gepland. Posts op Tweakers, het PVOutput-forum, Reddit, en specifieke zonne-energie-Facebook-groepen leveren wat eerste gebruikers op, maar exponentiële groei vraagt iets meer systematisch.

Wat ik onderschatte in technisch detail

Real-device-testen is onvervangbaar. SwiftUI ontwikkelen op de Mac-simulator voelt nauwelijks anders aan dan ontwikkelen voor de echte telefoon, totdat het wel anders is. Performance-issues, geheugen-druk, batterij-impact, layouts die op een real iPhone 13 mini er anders uitzien dan op een mac-simulator-iPhone-13-mini, dit zijn allemaal redenen om regelmatig op een echte telefoon te testen.

Widgets zijn moeilijker dan ze lijken. iOS-widgets zijn een apart subproject in elke app. Ze draaien in een aparte process, met een eigen levenscyclus, met strict beperkte geheugen en CPU-tijd. Wat in de hoofd-app werkt, werkt niet noodzakelijk in een widget. De widget-architectuur in HelioPeak heeft me waarschijnlijk meer hoofdpijn opgeleverd dan eender welk ander deel van de app, maar het resultaat (een widget op de lockscreen of het beginscherm die echt nuttig is) is een van de meest gewaardeerde features in de feedback van gebruikers.

Localization van datum, getal, en valuta is een minefield. "5.400 kWh" in Nederlandse stijl is "5.400" met punt als duizendscheidingsteken; "5,400" met komma als duizendscheidingsteken in Engelse stijl betekent letterlijk 5,4 in Nederlandse stijl. De juiste handling daarvan in alle hoekjes van een app, in alle zes talen, was meer werk dan ik had ingeschat.

Apple's Swift Charts zijn briljant maar onaf. Voor mijn grafieken gebruik ik het SwiftUI Charts framework van Apple. Het is uitstekend voor de meeste use-cases, maar het mist randzaken (specifieke aspect-ratio's bij export, specifieke gradiënten, sub-axis labels) die ik moest oplossen met combinaties van native Charts en custom overlays.

Wat ik leerde over indie-pricing

Mijn aanpak voor HelioPeak's pricing veranderde over tijd. Bij de initiële lancering in april 2026 was de IAP €2,99. Dat was te laag, en ik wist het. Bij versie 2.0 heb ik hem verhoogd naar €6,99, en zelfs dat voelt aan de lage kant gegeven de waarde die mensen uit de app halen over 25 jaar.

De redenering achter de prijs:

• Te laag bij start. €2,99 maakte de drempel laag voor gebruikers om te testen, maar zonder een eerlijke breakeven-prijs. Bij die prijs zou ik 100.000 gebruikers nodig hebben om mijn ontwikkeluren minimum tegen een normaal uurloon te dekken. Onmogelijk in deze niche.
• Eerlijk bij relaunch. €6,99 is nog steeds onder wat vergelijkbare apps vragen (PV Output is een abonnement van $25/jaar, wat over de 25-jaar levensduur van een installatie €600+ wordt). Maar het is een eerlijke prijs voor wat de app levert, in eenmalige vorm.
• No-subscription commitment. De core-app blijft een eenmalige aankoop. Een Pro-tier komt later voor features die werkelijke server-kosten met zich meebrengen (forecasting, multi-system-aggregatie), maar de basis blijft een eenmalige €6,99 voor wie hem koopt of al heeft.

Wat ik heb geleerd over conversiepercentages: het percentage gratis gebruikers dat naar paid converteert is laag (tussen 3 en 8% in mijn data tot nu toe). Dat betekent dat je gemiddelde opbrengst per gebruiker ligt in de range €0,20 tot €0,55, niet de €6,99 die je zou denken. Voor een niche-markt zoals zonne-monitoring betekent dit dat een werkelijke break-even alleen mogelijk is bij gebruikersaantallen in de duizenden, niet in de tientallen.

Wat ik leerde over de gebruikers

De HelioPeak-gebruikers zijn een verrassend specifieke groep. Een paar observaties:

Ze zijn ouder dan ik dacht. Gemiddeld 50+, mannen, technisch onderlegd, zonnepaneeleigenaars van 5+ jaar. Niet de hipste demografie voor app-marketing, maar wel een groep met de tijd en middelen om een fatsoenlijke app aan te schaffen en hem ook werkelijk te gebruiken.

Ze hebben echte verwachtingen van kwaliteit. Bug reports zijn precies, gedetailleerd, technisch onderbouwd. Een typische bug report van een HelioPeak-gebruiker beschrijft niet alleen wat er fout ging, maar ook welk toestel en welke iOS-versie, en bij voorkeur reproduceerbare stappen. Dit maakt mijn werk veel makkelijker en is iets dat ik in een meer mainstream app zou missen.

Ze zijn community-georiënteerd. Veel feedback komt via fora (Tweakers in Vlaanderen, PVOutput.org internationaal) eerder dan direct mail. Een gevolg is dat features die in de community circuleren, en die ik niet had bedacht, soms heel snel een wens van veel mensen blijken. De Notes-functie kwam vrijwel volledig uit forum-discussies.

Ze zijn loyaal als je het goed doet. Eens iemand de IAP heeft gekocht, blijft hij meestal. De churn in een eenmalige aankoop-model is sowieso laag, maar in een niche met een specifiek doelpubliek nog lager. Dit is mooi voor het langetermijn-financiële plaatje, maar het betekent ook dat negatieve feedback uitvergroot weegt: als ik een groep van 20 vroege adopters verlies, raakt me dat aanzienlijk meer dan in een mainstream app.

De kleine lessen die ik onverwacht waardevol vond

Een aantal kleine dingen die geen "lesson learned" lijken te zijn maar die voor mij wel impact hadden:

Een commit-script schrijven. Ik heb voor mijn project een shell-script dat na een goede stable build automatisch commit naar Git met een gestandaardiseerde message, naar GitHub pusht, en een log bijhoudt van versies. Dit klinkt triviaal, maar het schrappen van die mentale overhead bij elke release-commit maakte het werk merkbaar leichter.

TelemetryDeck integreren vanaf het begin. Anonieme gebruiksstatistieken (welke schermen, welke acties, welke OS-versies) zijn cruciaal voor het maken van productbeslissingen. Voor TelemetryDeck heb ik gekozen om hun privacy-bewuste model (gehashte signals, geen identifiers, EU-tenant), wat zowel mijn ethische lijn als mijn marketingverhaal beter ondersteunt.

Notities voor mezelf in code. Boven elk niet-triviaal codebestand schrijf ik wat de file doet, welke beperkingen hij heeft, welke recente wijzigingen ik heb gemaakt. Voor mijn toekomstige zelf, drie maanden later wanneer ik bij dat bestand terugkom, is dat een gouden archief. Anyone die ooit terug naar oude code is gekomen weet wat ik bedoel.

Echte gebruikers testen voor je echt klaar bent. Ik heb mijn vrouw, mijn broer, en een paar collega's de bèta laten testen, en hun feedback voor de v1.0-launch heeft me waarschijnlijk weken werk bespaard nadien. Een uur testen door iemand die geen developer is, levert meer inzicht op dan tien uur eigen QA.

Wat blijft

Op dit moment heb ik een paar honderd gebruikers van HelioPeak, met goede reviews op de App Store, een actieve community op Tweakers, en een lange backlog van features die ik wil bouwen. Dat is, in absolute zin, een klein resultaat in app-store-land. In persoonlijke zin, voor iemand die zonder Swift-ervaring begon, voelt het als een prestatie.

Wat ik vooral meeneem uit dit project, en wat ik aan iedereen die soortgelijke indie-ambities heeft zou aanbevelen:

Begin met iets waar je zelf de behoefte aan voelt. Niemand anders is een betrouwbaarder testgebruiker dan jezelf.

Reken met realistische tijdsinschattingen. Wat in code-tijd uitvoerbaar lijkt in een uur, kost vaak vijf uur als je alles erbij telt (testing, debugging, documentatie, marketing).

Hou de cyclus van iteratie kort en geef niet te veel om perfectie in versie 1. Het belangrijkste is een ding in gebruikershanden krijgen, want feedback van echte mensen verschuift je begrip van wat belangrijk is sneller dan eender welke planning op voorhand.

Bouw met privacy en met kwaliteit in gedachten vanaf het begin. Het is moeilijker om die principes toe te voegen aan een bestaand product dan om ze vanaf dag één in de architectuur te zetten.

En wees niet bang om eerlijk te zijn over wat je app niet doet. Een app die zegt "hier zijn drie dingen die ik goed doe, hier zijn vijf dingen die ik niet doe" wekt vaak meer vertrouwen dan een app die alles claimt.

Tot slot

HelioPeak is geen succesverhaal in financiële zin (nog niet), maar het is wel een succesverhaal in persoonlijke zin: ik heb iets gebouwd dat ik wilde, gepubliceerd in zes talen, op drie platformen, op tijd, en het wordt door echte mensen gewaardeerd. Voor een ontwikkelaar zonder voorafgaande iOS-ervaring is dat geen slechte uitkomst van een halfjaar avonden-en-weekenden werk.

De volgende horizon is een Apple Watch-versie, een Pro-tier met Forecast.Solar integratie, en uiteindelijk meer talen. Of het ooit een levensonderhoud wordt, blijft een open vraag. Maar als het dat niet wordt, heb ik nog steeds een goede app, een groeiende community, en een hobby waar ik mij in heb geleerd zoals zelden eerder.

Dat is dan misschien de stiekeme grootste les uit indie-ontwikkeling: het bouwen ervan is op zich al de moeite waard, ongeacht waar het uiteindelijk landt.