Hoeveel kost het om een goede app te laten ontwikkelen?

Achter elk bedrag zit een ander product

Als we spreken met teams die „een app willen laten bouwen“, begint het vaak met één zin: „We hebben eerst een bedrag nodig.“ En dan volgt de verwarring: De eerste offerte bedraagt 12.000 €, de volgende 80.000 €, en ergens op internet staat iets als „vanaf 5.000 €“.

De reden is zelden oplichting – het is de kostenblackbox, die ontstaat wanneer verschillende mensen verschillende producten in gedachten hebben.

Een app is geen enkelvoudig ding

„App“ kan betekenen: een kleine, installeerbare informatie-app zonder login. Of een klantenplatform met accounts, betalingsverwerking, pushmeldingen, adminpaneel en koppeling met je bestaande systeem. Dat zijn twee totaal verschillende bouwwerken.

Wij gebruiken intern graag een beeld: Je kunt „een huis“ bouwen – als tiny house of als appartementencomplex met ondergrondse garage. Beide heten huis. Beide hebben deuren. Maar de prijs heeft geen gemeenschappelijke taal.

Misvatting nummer één: Features tellen niet simpelweg op

Veel mensen denken dat functies als Legoblokjes zijn: eentje erbij, een beetje duurder. In de praktijk zijn features met elkaar verbonden. Een login heeft plotseling gevolgen voor rechten, gegevensbescherming, foutmeldingen, e-mailflows, wachtwoordreset, analytics en support.

Onze methode 1: De vertaling in drie vragen

Om offertes vergelijkbaar te maken, vertalen we elk idee eerst naar drie vragen:

1) Hoeveel gebruikersflows zijn echt kritisch? (bijv. „Zoeken“, „Boeken“, „Betalen“)

2) Hoeveel datalogica zit erachter? (Backend ja/nee, synchronisatie, rollen)

3) Hoe groot is je risico, als er iets misgaat? (Beveiliging, beschikbaarheid, aansprakelijkheid)

Als deze drie antwoorden duidelijk zijn, wordt „app“ een project. En dan wordt de prijs ineens verklaarbaar – als bandbreedte, niet als raadsel.

Tussendoor: We zien vaak dat teams uit angst voor het budget te vroeg „goedkoop“ gaan optimaliseren. Dat leidt zelden tot lagere kosten, maar tot meer iteraties. Het goede nieuws: Juist deze iteraties kun je vermijden als je eerst duidelijkheid inkoopt – geen code.

Als grove richtlijn noemen internationale benchmarks voor eenvoudige apps 5.000–50.000 $, voor middelgrote 50.000–120.000 $ en voor complexe 120.000–300.000 $+. Business of Apps (2025)↗

Goede planning werkt met bandbreedtes en aannames

„Wat kost een goede app?“ kun je het eerlijkst als volgt beantwoorden: In bandbreedtes, niet in exacte bedragen – en altijd inclusief context.

Als je in de DACH-regio professioneel laat ontwikkelen, zien we in de praktijk drie typische categorieën. Een ervaren app-ontwikkelaar uit het Duitstalige gebied noemt als richtwaarden ongeveer 20.000–45.000 € voor eenvoudige apps, 45.000–110.000 € voor middelgrote en 110.000–300.000 €+ voor complexe enterprise-apps. app-entwicklerin.de (Schulte, 2025)↗

Deze cijfers lijken hoog in vergelijking met „vanaf 5.000 €“, maar sluiten vaak beter aan bij wat de meeste mensen werkelijk bedoelen als ze „een goede app“ zeggen: goed ontworpen, stabiel, veilig, onderhoudbaar.

Een paar concrete beelden

Een „eenvoudige app“ is bij ons zelden een fantasie-app, maar eerder iets als: content weergeven, weinig interacties, misschien een formulier – zonder maatwerkbackend. Hier kan een kleine scope zeker in het bereik van ongeveer 20–45k vallen, als design, een nette implementatie en het releaseproces inbegrepen zijn.

Een „middelgrote app“ heeft meestal een login, rollen, een admin-interface of een eigen backend. Precies hier vallen veel Purpose-projecten onder: community, boekingen, educatieve content, donatie- of afsprakenlogica.

„Complex“ wordt het zodra je meerdere apps tegelijk nodig hebt (bijv. gebruikersapp plus admin plus dienstverlenersapp), offline-synchronisatie of hoge beveiligingseisen. Bij platformideeën („zoals Uber, maar voor …“) loopt het al snel op tot zes cijfers. Voor Uber-achtige systemen worden alleen al per platform vaak 50.000–150.000 $ genoemd – en dat is slechts het begin als je het hele systeem bekijkt. mobian.studio↗

Regio en team veranderen het bedrag – niet de natuurkunde

Internationale uurtarieven variëren sterk (goedkopere regio's liggen daar duidelijk onder, senior-teams in Europa/VS duidelijk boven). Maar de natuurkunde blijft: tijd voor design, ontwikkeling en tests verdwijnt niet alleen omdat het uurtarief lager is.

Wat we je willen meegeven: Stel eerst een doel voor de eerste versie. Daarna zoek je de passende range. Niet andersom.

En nog een reality-check uit het oprichtersmagazine: Een studie noemt gemiddeld ongeveer 30.000 € aan app-kosten en een terugverdientijd van ongeveer 12 maanden. StartingUp.de↗

Kwaliteit blijkt uit stabiliteit en doorontwikkeling

Een goede app herken je zelden aan het feit dat hij „veel kan“. Je herkent hem eraan dat hij rustig is: Hij voelt helder aan, crasht niet, reageert snel, beschermt gegevens – en je kunt hem over een jaar nog verder ontwikkelen, zonder alles opnieuw te bouwen.

Kwaliteit kost – en bespaart later bijna altijd

Wij zien „goed“ als een mix van vier dingen: UX, stabiliteit, veiligheid en toekomstbestendigheid.

UX betekent niet alleen „mooi“, maar: Je begrijpt zonder na te denken wat je moet doen. Precies daarom investeren veel teams meer in design dan ze aanvankelijk vermoeden. In budgetverdelingen zien we voor design vaak rond de 20–25 % – niet als luxe, maar als onderdeel van risicoreductie. Business of Apps (2025)↗

Stabiliteit betekent: De app draait op echte apparaten, met een haperende verbinding, met lege accu's, met mensen die „vreemd“ tikken. Dat is het moment waarop testen plotseling geen bijzaak meer is. Ook hier noemen brancheanalyses vaak 10–15 % van het budget voor testen en deployment. Business of Apps (2025)↗

Veiligheid is niet alleen een onderwerp voor banken. Zelfs een eenvoudig gebruikersaccount brengt verantwoordelijkheid met zich mee. We merken dat „goedkope“ aanbiedingen vaak juist hierop besparen – niet uit kwade wil, maar omdat security-werk moeilijk zichtbaar te maken is.

Toekomstbestendigheid is onze stille favoriet. Die ontstaat door een goede architectuur, nette documentatie en beslissingen die onderhoud mogelijk maken. Dat klinkt onromantisch, maar het is precies wat van een eenmalig project een duurzaam product maakt.

Frisse invalshoek 1: Goede apps worden niet „gebouwd“, ze worden „beheerd“

De grootste denkfout is de fixatie op de lancering. Een app is niet af wanneer hij in de store staat. Een goede app heeft een plan voor de volgende releases, een meetlogica (Analytics) en een duidelijk beeld van welke gebruikersproblemen hij als volgende oplost.

Deze blik verandert ook de budgetvraag: Je vraagt niet alleen „Wat kost versie 1?“, maar „Wat kost het om 12 maanden goed te blijven?“ Precies daar begint voor ons kwaliteit – en precies daar scheiden „werkt op de een of andere manier“ en „werkt echt“ zich van elkaar.

Als je in deze richting denkt, wordt het budget niet kleiner, maar zinvoller. En plotseling is het veel gemakkelijker om intern of tegenover investeerders uit te leggen waarom je niet alleen code koopt, maar betrouwbaarheid.

Het soort functie bepaalt de benodigde inspanning

Als we budgetten uitleggen, proberen we nooit kosten te rechtvaardigen. We maken ze zichtbaar. En ze worden zichtbaar daar waar jij beslissingen neemt.

Feature-realiteit in plaats van featurelijst

De sterkste drijfveer is bijna altijd de functionaliteit – maar niet als aantal, maar als soort van de functies. Een kalender is niet automatisch duur. Hij wordt duur wanneer de kalender kan boeken, capaciteiten beheert, annuleringen verwerkt, facturen triggert en met een bestaand systeem moet communiceren.

De backend is daarbij de klassieke verrassingspost. Veel mensen zien alleen de app op de telefoon. Maar zodra gebruikersaccounts, datasynchronisatie, pushmeldingen of adminfuncties in het spel komen, bouw je op de achtergrond een tweede product: API's, database, rechten, monitoring.

Integraties drijven de kosten bijzonder betrouwbaar op: betaalproviders, CRM, lidmaatschapssystemen, kaarten, e-mail, identiteitsproviders. Elke integratie is niet alleen „aansluiten“, maar ook testen, beveiligen, foutgevallen definiëren.

Offline, beveiliging, apparaatfuncties: de verborgen vermenigvuldigers

Offlinefunctionaliteit klinkt klein, maar is vaak een vermenigvuldiger: lokale opslag, conflictoplossing bij synchronisatie, datamigratie. Hetzelfde geldt voor gevoelige gegevens: een relatie met gezondheid of financiën betekent meer beveiligingswerk.

En dan zijn er de apparaatfuncties: camera, Bluetooth, sensoren, realtime locatie. Alles wat „dicht“ bij het apparaat zit, vereist meer testen op echte apparaten.

Onze methode 2: De „drie-lagen-scope“

Om de planning rustiger te maken, delen we features op in drie lagen:

1) Must: Zonder dit is er geen nut.

2) Proof: Dit bewijst de meerwaarde (vaak 1–2 functies).

3) Polish: Dit maakt het geheel af (animaties, comfort, extra's).

We ontwikkelen eerst Must en Proof en houden Polish bewust flexibel. Dat is geen bezuinigingsmaatregel uit principe, maar een beslissing tegen budgetverrassingen.

Frisse invalshoek 2: Niet „Wat is mogelijk?“, maar „Wat is bewijsbaar?“

Als je een app bouwt om impact te creëren – meer toegang tot leren, minder verspilling, betere zorg – dan telt wat je in de eerste versie echt kunt aantonen. Deze manier van denken verschuift je budget van „alles één keer“ naar „het belangrijkste goed doen“.

Zo wordt de goede app niet de duurste. Maar degene die sneller laat zien waarom hij bestaat.

Budget volgt een proces, niet alleen features

Een app lijkt naar buiten toe een product. Vanbinnen is het een proces met duidelijke fasen. Als je begrijpt, waar geld doorgaans naartoe vloeit, kun je offertes veel beter lezen – en je ziet snel of iemand realistisch plant.

We zien vaak de volgende logica: Aan het begin staat Discovery (doel, gebruiker, scope, technische richting). Daarna komt UX/UI-design (flows, prototype, visuele taal). Vervolgens ontwikkeling (frontend en backend), testen en lancering.

Brancheanalyses laten zien dat bedrijven voor Discovery vaak 10–20 % uitgeven en voor design ongeveer 20–25 %. Business of Apps (2025)↗ Ontwikkeling is meestal het grootste blok, testen en deployment liggen vaak op 10–15 %. Business of Apps (2025)↗

Wat betekent dat praktisch voor jou?

Als een offerte Discovery en design bijna overslaat, lijkt die op het eerste gezicht goedkoper. In werkelijkheid betaal je dan vaak later – met nabewerking, koerswijzigingen of een product dat weliswaar „af“ is, maar gebruikers niet overtuigt.

Juist Purpose-projecten hebben vaak een bijzondere uitdaging: De app moet niet alleen functioneren, maar ook vertrouwen verdienen. Dat ontstaat door duidelijkheid en toegankelijkheid. Daarvoor is tijd nodig in design en tests.

Een kleine, eerlijke minirekening

Laten we uitgaan van een gemiddelde app. Als je denkt aan een totaalbudget van 60.000 €, zijn 6.000–12.000 € voor Discovery geen „overhead“, maar een verzekering tegen verkeerde aannames. En 12.000–15.000 € voor design zijn vaak het verschil tussen „ik gebruik het één keer“ en „ik blijf het gebruiken“.

Frisse invalshoek 3: Discovery is de goedkoopste vorm van moed.

Veel teams willen „snel beginnen“, omdat het idee aandringt. We begrijpen dat. Maar uit ervaring is de snelste weg naar de lancering vaak degene die één keer kort stilstaat en het project zo beschrijft dat het gebouwd kan worden.

Als je meer wilt lezen over de aanpak van digitale projecten: In ons plan „Momentum“ beschrijven we hoe we van idee tot exploitatie werken.

Technologie verdeelt kosten over de gehele looptijd

De platformkeuze voelt vaak als een geloofskwestie: eerst iOS? Android? Beide? Of meteen een PWA?

We lossen dat niet op met dogma's, maar met een simpele observatie: Technologie is een kostenpost over tijd. Niet alleen bij het bouwen, maar ook bij het onderhouden.

Native, Cross-Platform, PWA: wat je werkelijk koopt

Native ontwikkeling (twee codebases) kan zinvol zijn als je extreem platformspecifieke eisen hebt of als performance echt kritisch is.

Cross-Platform (bijv. Flutter) kan daarentegen veel efficiëntie opleveren, omdat grote delen van de logica één keer worden gebouwd. Een DACH-bron noemt als praktijkwaarde dat Flutter tot 40 % goedkoper kan zijn dan twee native apps. app-entwicklerin.de (Schulte, 2025)↗

PWA's kunnen voor bepaalde use-cases een eerlijke alternatief zijn, juist als je product eerder service- of contentgericht is en je snel wilt itereren. Ze zijn niet „beter“ of „slechter“, maar ze veranderen de kostenstructuur: vaak goedkoper bij de start, soms beperkt bij apparaatfuncties.

Uurtarief is niet hetzelfde als prijs

Internationale benchmarks laten extreme verschillen zien in uur- en salarisniveaus. Business of Apps (2025)↗ Dat verklaart waarom offshore-aanbiedingen aanzienlijk lager kunnen zijn. Tegelijkertijd nemen coördinatie, kwaliteitscontrole en het risico op misverstanden vaak toe. We zeggen dat zonder drama: het kan goed werken – maar het is een eigen project dat in de planning en begroting moet worden meegenomen.

Onze beslisroute

Als je snel op de markt moet komen en de app geen exotische hardwarefuncties heeft, neigen we vaak naar cross-platform.

Als je maximale integratie en zeer specifieke platform-UX nodig hebt, kan native zinvol zijn.

Als je eerst impact wilt bewijzen en je product eerder een „digitale service“ is, kijken we serieus naar een PWA – juist omdat je daarmee sneller kunt leren.

Voor een introductie in PWA-strategieën raden we dit overzicht aan als goede basis: Google Web.dev over PWA's.

Uiteindelijk is de techniekvraag zelden technisch. Ze is strategisch: Wil je sneller leren, sneller groeien of maximaal perfect starten? Je budget volgt deze beslissing.

Het tweede jaar hoort in de eerste begroting

We maken het steeds weer mee: Een team plant € 60.000 voor de ontwikkeling in – en € 0 voor het jaar daarna. Dat is menselijk. Maar het is ook het moment waarop goede apps plotseling „te duur“ lijken, terwijl eigenlijk alleen het verkeerde onderdeel was gepland.

Na de lancering begint het echte werk

Nieuwe iOS- en Android-versies komen regelmatig, apparaten veranderen, bibliotheken krijgen beveiligingsupdates. Daar komen dingen bij die je pas na echte gebruikers leert: Waar haken ze af? Wat begrijpen ze niet? Welke functie wordt verrassend vaak gebruikt?

Voor onderhoud en doorontwikkeling noemen ervaren praktijkmensen vaak een richtwaarde van ongeveer 15–20 % van de oorspronkelijke ontwikkelingskosten per jaar. app-entwicklerin.de (Schulte, 2025)↗

Dat betekent niet dat je elk jaar „nog eens zoveel“ betaalt. Het betekent: Je plant bewust tijd in voor stabiliteit, kleine verbeteringen, aanpassingen en beveiliging.

Exploitatiekosten zijn zelden het probleem – verrassingen wel

Daarnaast is er infrastructuur: servers, database, e-mail, pushdiensten, eventueel externe API's. Soms zijn dat een paar tientjes per maand, soms aanzienlijk meer – afhankelijk van hoe datarijk je product is.

En ja: appstores kosten ook geld. Apple vraagt voor het Developer Program een jaarlijkse vergoeding, Google een eenmalige registratie. Dat zijn geen enorme posten, maar ze horen bij het „levend houden“.

Onze blik als duurzaam digitaal bureau

Hier komt een perspectief om de hoek kijken dat we in veel kostenartikelen missen: Performance is niet alleen UX, het zijn ook exploitatiekosten. Als je efficiënt ontwikkelt, minder data overdraagt en nette media gebruikt, dalen de infrastructuur- en onderhoudsdruk. Dat is voor ons „Groen Design“ in het dagelijks leven: niet moralistisch, maar praktisch.

Daarom plannen we al vroeg hoe de app later kan worden bijgewerkt, hoe logging en monitoring eruitzien en hoe je niet in een tool-lock-in terechtkomt. Misschien is dit niet het spannendste hoofdstuk – maar het is wel het hoofdstuk dat op de lange termijn geld bespaart en vertrouwen beschermt.

Als je je wilt verdiepen in analytics en crashrapportage: Firebase Crashlytics is een goed startpunt om fouten vroeg te zien en onderhoud beter planbaar te maken.

Waarde ontstaat uit een duidelijke zakelijke taak

Kosten zijn maar de helft van het verhaal. De andere helft is: Waar betalen jullie eigenlijk voor? En hoe merken jullie of het de moeite waard is?

We hebben goede ervaringen met het niet behandelen van ROI als een grote bedrijfseconomische theorie, maar als een eenvoudige, menselijke vraag: „Welke verandering moet deze app in het dagelijks leven teweegbrengen?“ Als dat duidelijk is, wordt rendabiliteit ineens concreet.

Drie soorten rendement die we in projecten zien

Ten eerste: Directe omzet (abonnement, in-app-aankopen, transacties). Ten tweede: indirecte omzet (meer herhaalaankopen, betere binding, de app als betrouwbaar contactpunt). Ten derde: Kostenbesparing (minder handmatig werk, minder support, minder fouten).

Een studie in het oprichtersmagazine meldt dat apps gemiddeld na ongeveer 12 maanden winst opleveren. StartingUp.de↗ Wij nemen dat graag als aanmoediging – en zeggen er tegelijkertijd bij: dat is een gemiddelde, geen belofte.

Onze praktische ROI-methode: het 3-cijferverhaal

Om het niet vaag te laten blijven, werken we met drie cijfers die je meestal al vóór de eerste regel code kunt benoemen:

1) Hoe vaak vindt het „kernmoment“ per maand plaats? (bestelling, boeking, donatie, gebruik)

2) Wat is het waard – in geld of tijd? (bijdragemarge, bespaarde minuten)

3) Hoeveel maanden geef je de app om te leren?

Een voorbeeld uit de typische realiteit van het mkb: Als een app elke week 30 telefoongesprekken door selfservice vervangt, bespaart dat al snel merkbaar veel werktijd. Bij interne apps is de ROI vaak het duidelijkst, omdat je de tijd direct ziet.

Voor Purpose Brands komt daar een vierde return bij

Bij organisaties met een missie komt er nog iets bij: Impact. Als je app ervoor zorgt dat meer mensen toegang krijgen, er minder middelen worden verbruikt of donaties regelmatiger binnenkomen, dan is „return“ niet alleen euro.

Dat verandert onze kijk op kosten: We beoordelen niet alleen „goedkoop vs. duur“, maar „effect per geïnvesteerde euro“. En vaak is een solide, goed geteste app hier de goedkopere keuze – omdat die vertrouwen verdient en daardoor überhaupt wordt gebruikt.

Als je je wilt verdiepen in app-monetisatie: Wij vinden de aanwijzingen over modellen en valkuilen uit het oprichtersmagazine een nuttig startpunt. StartingUp.de↗

Doordachte architectuur voorkomt digitale slijtage

Als we als Pola over kosten praten, hebben we het nooit alleen over „hoe goedkoop kan het“. We hebben het over hoe zinvol blijft het.

Duurzaamheid is een kostenprofiel, geen sticker

Een app kan middelen verbruiken: datatransmissie, rekenkracht, onnodig zware media, steeds nieuwe apparaatvereisten. Duurzamer ontwikkelen betekent voor ons vooral: performance serieus nemen, onnodige complexiteit vermijden en technologie zo kiezen dat die lang onderhoudbaar blijft.

Dat klinkt als „meer inspanning“ – en ja, soms kost goede planning in het begin wat meer. Maar tijdens het gebruik zien we vaak het tegenovergestelde effect: Minder storingen, minder hectische fixes, minder verrassingen in de infrastructuur. Precies daarom past duurzaamheid zo goed bij de budgetvraag: Het maakt kosten op de lange termijn rustiger.

Inclusie is geen extra functie

Toegankelijkheid wordt bij apps verrassend vaak pas aan het einde ontdekt. Dan wordt het duur, omdat je UI-beslissingen achteraf moet repareren. Als je daarentegen al vroeg plant met screenreadergebruik, voldoende contrasten, begrijpelijke taal en duidelijke focusvolgordes, blijft de extra inspanning overzichtelijk.

Voor Purpose Brands is dit niet alleen „leuk“ – het is onderdeel van de houding: toegang voor iedereen. En puur economisch gezien bereik je daarmee meer mensen en verminder je de supportinspanning, omdat minder gebruikers op hindernissen vastlopen.

Frisse invalshoek 4: Kwaliteit als sociale verantwoordelijkheid

Wij geloven dat software niet neutraal is. Een instabiele app kost niet alleen geld, maar ook vertrouwen – en soms echte kansen, bijvoorbeeld wanneer mensen afhankelijk zijn van hulp of informatie nodig hebben.

Daarom bouwen we kwaliteit niet als „premium“, maar als standaard. En we praten er open over wat dat voor het budget betekent.

Als je je grofweg aan best practices wilt oriënteren: De OWASP Mobile Security Testing Guide helpt om beveiligingseisen concreter te maken – ook voor niet-technici die offertes willen beoordelen.

Een goede MVP bewijst eerst de centrale hypothese

Kosten verlagen klinkt vaak als „minder kwaliteit“. In onze projecten is het eerder: minder onduidelijkheid.

MVP is niet klein, maar gefocust

Een MVP is geen halve app. Het is de eerste versie die een hypothese bewijst. Als je een budgetlimiet hebt, is de MVP geen compromis, maar de professionele manier om risico te verminderen.

We beginnen daarvoor graag met een zeer concreet doel: „Over 8 weken moet een echte gebruiker het kernmoment één keer succesvol doorlopen.“ Niet „alles af“, maar „de belangrijkste route zonder haperingen“.

Standaardservices slim gebruiken

Een veelvoorkomend misverstand: Ofwel „alles zelf bouwen“ of „bouwpakket“. Daartussenin ligt de goede middenweg: diensten gebruiken waar ze tijd besparen, maar de architectuur zo ontwerpen dat je later niet vastzit.

Voor auth, push of crashrapportage zijn platforms zoals Firebase vaak een pragmatisch startpunt – zolang duidelijk is welke doorlopende kosten ontstaan en welke gegevens waarheen stromen.

Scopebeheer zonder frustratie

We proberen veranderingen niet tegen te houden, maar te ordenen. Want in bijna elk project leer je onderweg iets nieuws.

Daarvoor gebruiken we een eenvoudige regel: Als er iets nieuws bijkomt, moet er iets anders uit of naar achteren. Zo blijven budget en tijd eerlijk.

En we testen vroeg. Niet „aan het einde“. Want fouten die laat aan het licht komen, zijn duur – niet alleen financieel, maar ook mentaal.

Tot slot een zin die we vaak zeggen als het krap wordt: Bespaar niet op het nadenken. Bespaar op het onnodige.

Als je je momenteel afvraagt of je eerst een website, een PWA of direct een app nodig hebt: Onze kijk op digitale basisprincipes kan helpen voordat je een keuze maakt. Website laten maken

Risico's en aannames horen naast de prijs

Als je twee offertes naast elkaar legt, is de duurste vraag niet „waarom zoveel“, maar: Waar is het precies voor?

Vaste prijs of Time Material

Een vaste prijs voelt veilig. Maar het werkt alleen als scope en aannames echt stabiel zijn. Anders zit er een risicobuffer in de prijs – of eindigt het project in discussies over change requests.

Time and Materials (afrekening op basis van bestede tijd en materialen) kan eerlijker zijn als je nog leert en prioriteiten verschuiven. Dan heb je echter goede transparantie nodig: Wat is er gedaan, wat komt er als volgende, hoeveel budget is er nog.

Drie dingen die we altijd in offertes zoeken

Ten eerste: Is er een duidelijke beschrijving van de eerste versie – bij voorkeur als gebruikersflows, niet als buzzwords.

Ten tweede: Zijn design, testing en release expliciet ingepland. Als testing ontbreekt, is het niet „gratis“, het is alleen onzichtbaar.

Ten derde: Hoe wordt er over beheer en onderhoud gedacht. Een app zonder plan voor updates is als een winkel zonder sleutel.

Een tip uit ervaring: „Goedkoop“ kan betekenen dat je later geen vrijheid hebt

Let erop van wie de code is, of je documentatie krijgt en of de technologie begrijpelijk is gekozen. Wij geven de voorkeur aan duurzame, goed onderhoudbare technologieën en open standaarden, omdat ze de kans verkleinen dat je na een jaar weer bij nul begint.

Als je zelf geen technisch persoon in het team hebt, helpt een kleine tegenvraag in het gesprek: „Wat zijn de twee grootste risico's in dit project – en hoe plannen jullie die in?“ Het antwoord zegt vaak meer dan elke prijstabel.

En als je referenties wilt zien: kijk niet alleen naar „mooie schermen“, maar vraag naar wat in het dagelijks gebruik telt: stabiliteit, doorontwikkeling, samenwerking.

In Pola-projecten gebruiken we hiervoor transparantie in tools en processen – onder andere via een centrale workspace voor tickets, status en beslissingen. Dit is geen extra. Het is een vorm van eerlijkheid: je moet op elk moment begrijpen waarvoor je betaalt.