Wat een maatwerk-app echt kost: een eerlijke, transparante uitsplitsing

Vraag drie bureaus wat een maatwerk-app kost en u krijgt drie getallen die nog niet één cijfer gemeen hebben. De één zegt vierduizend, de ander veertig, en de derde mompelt dat het ervan afhangt en plant een tweede gesprek. Geen van hen liegt, niet echt — maar geen van hen vertelt u wat u werkelijk moet weten: waar het geld heen gaat en waarom uw specifieke app uitkomt waar hij uitkomt. Laten we dus de motorkap openen.

Ik heb meer app-offertes geschreven dan ik kan tellen, voor bedrijven variërend van een eenmanszaak in de vakhandel tot een regionale keten. De meest voorkomende reactie op een prijs is niet schrik over het totaal — het is verwarring over de spreiding. Hoe kan dezelfde briefing van drie woorden ("een boekingsapp") schattingen opleveren die een factor tien verschillen? Het eerlijke antwoord is dat "een boekingsapp" geen briefing is. Het is een wens. De prijs schuilt in de honderd kleine beslissingen die eronder verborgen liggen.

Dit stuk is de uitsplitsing die ik elke ondernemer gun vóór zijn eerste gesprek met een ontwikkelaar. Geen opvulling, geen bangmakerij, geen upsell. Gewoon de echte kostenposten, de dingen die stilletjes een budget verdubbelen, en een paar eerlijke manieren om minder uit te geven zonder met iets te eindigen waar u spijt van krijgt.

Waarom twee offertes voor "dezelfde app" een factor 10 verschillen

Software is geen product dat u zo van de plank pakt — het is arbeid, gemeten in de uren van vakkundige mensen. De prijs van een maatwerk-app is dus in de kern simpelweg omvang × uurtarief × risico. Al het andere is een voetnoot bij die drie dingen. Wanneer twee offertes sterk uiteenlopen, wordt een van die drie getallen heel anders gelezen, en meestal heeft niemand dat hardop gezegd.

De omvang is het voor de hand liggende. "Een boekingsapp" kan één scherm betekenen waarop klanten een tijdslot kiezen — of het kan personeelsagenda's, betalingen, herinneringen, een klantlogin, een beheerdersdashboard, terugbetalingen en een rapport betekenen dat de eigenaar op maandag leest. Dezelfde drie woorden, tien keer zoveel werk. De goedkope offerte gaat vaak uit van de kleine versie; de dure neemt stilletjes de grote aan. Geen van beide vroeg u welke u bedoelde.

Dan is er risico, het deel dat niemand graag beprijst. Een vage briefing, een klant die nog niet heeft besloten wat hij wil, een koppeling met een gammel verouderd systeem — die voegen niet alleen uren toe, ze voegen onzekerheid toe. Ervaren teams rekenen een marge voor onzekerheid omdat ze er hun vingers aan hebben gebrand. Een goedkopere offerte heeft het risico vaak helemaal niet beprijsd, en dat is precies waarom hij soms halverwege uit zijn voegen barst.

Waar het geld werkelijk heen gaat

Als mensen zich appontwikkeling voorstellen, denken ze aan programmeren. Programmeren is reëel, maar het is zelden zelfs de helft van de rekening. Een maatwerk-app lijkt meer op het bouwen van een klein huis dan op het schrijven van een document — er zit ontwerp, leidingwerk, inspectie en papierwerk rond het zichtbare deel. Zo verdeelt een typisch budget zich zodra u alles meerekent.

Twee dingen verrassen mensen meestal in die tabel. Ten eerste hoeveel van het budget plaatsvindt voordat er één regel functiecode is geschreven — verkenning en ontwerp zijn geen luxe, het is de goedkoopste plek om een fout te herstellen. Een scherm wijzigen in een schets kost minuten; het wijzigen nadat het is gebouwd kost dagen. Ten tweede hoe reëel de testpost is. Hem overslaan bespaart geen geld, het verschuift de kosten alleen naar uw lanceringsweek, met rente.

Verkenning en ontwerp: het deel dat iedereen wil overslaan

Verkenning is waar u "een boekingsapp" omzet in een precieze lijst van schermen en regels. Het voelt als overhead omdat er nog niets gebouwd wordt. Maar elk uur hier bespaart er meerdere verderop, want het is waar dubbelzinnigheid wordt uitgeschakeld terwijl het nog goedkoop is. Een team dat u een prijs offreert zonder verkenningsfase gokt ofwel, of is van plan u de verkenning later onder een andere naam in rekening te brengen.

Kernontwikkeling: de zichtbare motor

Dit is de code die uw idee laat draaien — de schermen waarop mensen tikken, de logica erachter en de database die stilletjes alles onthoudt. Het is de grootste enkele post, en hij schaalt vrijwel direct mee met de omvang. Elke functie die u toevoegt, is meer om te bouwen, meer om te testen en voor altijd meer om te onderhouden. Dit is de post waar "zou het niet leuk zijn als" snel duur wordt.

Integraties: het bedrieglijk prijzige stukje

Uw app verbinden met andere systemen — een kaartbetaling aannemen, een sms-herinnering versturen, een agenda synchroniseren, gegevens ophalen uit de boekhoudsoftware die u al gebruikt — lijkt klein op een functielijst en valt verrassend zwaar uit op de factuur. Elke koppeling is een klein project op zich, met zijn eigen eigenaardigheden en faalwijzen. Eén keurige betalingsintegratie is prima. Vijf verstrengelde integraties met een verouderd intern systeem, daar gaan budgetten dood.

De kosten die niemand in de offerte zet

Hier krijgen veel ondernemers na twaalf maanden een nare verrassing. De bouw is een eenmalig bedrag; een app is geen eenmalig ding. Software leeft — telefoons werken bij, regels veranderen, uw bedrijf groeit — en een levend ding heeft voeding nodig. De offerte die u tekent is de prijs van geboorte, niet de prijs van eigendom.

Niets hiervan is oplichterij of een verborgen valstrik — het is gewoon het deel dat niet netjes op een offerte van één pagina past, dus zwakkere partners laten het weg om goedkoper te lijken. Een goede vertelt het u vooraf, ook al laat het hun eerste getal groter lijken. Vraag het expliciet: wat kost dit mij om een jaar te draaien na lancering? De kwaliteit van het antwoord zegt u veel over met wie u te maken hebt.

Wat de prijs stilletjes verdubbelt

Sommige dingen voegen kosten toe in verhouding tot de waarde die ze brengen — terecht. Andere voegen kosten toe volledig buiten verhouding, meestal vanwege hoe het werk is gestructureerd in plaats van wat de app doet. Dit zijn de hefbomen die de moeite waard zijn om te begrijpen, want een paar ervan hebt u volledig in eigen hand.

• Twee platforms in plaats van één. Een native iPhone-app en een native Android-app zijn, grofweg, twee bouwwerken. Cross-platformtools of een webapp kunnen dat terugbrengen naar één. Deze ene keuze kan het totaal meer verschuiven dan welke functie ook.
• Maatwerkontwerp boven verstandige standaarden. Een pixelperfecte, volledig op maat gemaakte interface kost echt geld om te ontwerpen en te bouwen. Een strakke, conventionele die beproefde patronen gebruikt is sneller, goedkoper en vaak makkelijker in gebruik voor klanten.
• Van gedachten veranderen nadat de bouw is begonnen. Beslissingen zijn goedkoop op een whiteboard en duur in code. De meest voorkomende budgetoverschrijding is geen slechte schatting — het is een omvang die bleef groeien omdat niets was vastgelegd.
• Real-time, offline of zware data. "Het moet werken zonder bereik" of "updates moeten voor iedereen direct verschijnen" zijn redelijke verzoeken die de techniek eronder stilletjes vermenigvuldigen.
• Koppelen aan iets ouds en ongedocumenteerds. Verbinden met een modern, goed gebouwd systeem is routine. Verbinden met een vijftien jaar oud intern hulpmiddel zonder documentatie is archeologie, en het wordt per uur in rekening gebracht.

Een echt voorbeeld: de offerte van €60.000 die een app van €14.000 werd

Een paar details zijn aangepast voor de privacy, maar de vorm hiervan is waar en volledig typerend. Een regionaal dienstverlenend bedrijf — denk aan een tiental buitendienstmedewerkers en een druk kantoor — kwam gefrustreerd bij ons. Ze wilden een maatwerk-app waarmee hun klanten klussen konden boeken, de voortgang konden volgen en konden betalen. Ze hadden elders al een offerte gehad van rond de €60.000, plus een stevig maandbedrag, en dat had hen het hele idee bijna een jaar lang doen afzien.

Toen we daadwerkelijk in kaart brachten wat ze nodig hadden — niet wat hen was geofferd — zag het plaatje er heel anders uit. De eerste offerte ging uit van twee volledig native apps, een maatwerkontwerp vanaf nul, een real-time dispatchsysteem en een maatwerk-beheerplatform om hulpmiddelen te vervangen die ze al bezaten en waar ze stilletjes blij mee waren. Het was, technisch gezien, een perfect goede app. Het was ook een antwoord op een vraag die ze niet hadden gesteld.

Wat we daadwerkelijk deden

We besteedden de eerste sessies aan niets dan verkenning — de wens uit elkaar trekken in "het bedrijf valt zonder dit stil" tegenover "dat zou ooit leuk zijn". De must-haves waren smaller dan iemand verwachtte: een nette manier voor klanten om een klus aan te vragen en te volgen, automatische herinneringen en online betaling. De real-time dispatch en het maatwerk-backoffice bleken oplossingen voor problemen die hun bestaande software al prima afhandelde.

1. 1
   De omvang teruggebracht tot de echte klus

   We schrapten de functies die problemen oplosten die ze niet hadden, en hielden een strakke lijst over waar het bedrijf echt niet zonder kon.
2. 2
   Eén cross-platform-bouw gekozen

   In plaats van twee aparte native apps dekte één cross-platform-app zowel iPhone als Android — ongeveer een halvering van de kernontwikkeling.
3. 3
   Beproefde ontwerppatronen gebruikt

   Een strakke, conventionele interface in plaats van een op maat gemaakte. Klanten vonden hem makkelijker in gebruik, en het scheelde weken in de planning.
4. 4
   Gekoppeld, niet vervangen

   We verbonden de app met de kantoorsoftware waarvoor ze al betaalden, in plaats van die opnieuw te bouwen. Het dure 'maatwerk-beheerplatform' verdween simpelweg uit de omvang.

Het resultaat was een bouw van rond de €14.000, in een paar maanden live, met voorspelbare doorlopende kosten. Hij is niet zo uitgebreid als de versie van €60.000 — en dat hoeft ook niet. Hij doet de klus die het bedrijf werkelijk had. Een jaar later hebben ze er twee kleine functies bovenop toegevoegd, betaald uit het geld dat de eerste versie hen bespaarde. Dat is het hele patroon: begin met de echte klus, verdien de extra's met resultaten.

Hoe u de kosten beheersbaar houdt zonder bochten af te snijden

Minder uitgeven aan een maatwerk-app gaat niet over het uurtarief omlaag pingelen of het goedkoopste team vinden dat u kunt. Zo betaalt u uiteindelijk twee keer. Het gaat over bewust omgaan met omvang, volgorde en beslissingen — de drie dingen die het getal werkelijk verschuiven. Hier zit de echte besparing.

Ten eerste, bouw de kleinste versie die werkelijk nuttig is en laat hem dan groeien. Een gefocuste eerste release die één klus goed doet, brengt u sneller live, kost een fractie van de alles-in-één-droom en — cruciaal — leert u wat u vervolgens moet bouwen op basis van echte klanten in plaats van gissingen. Ten tweede, neem uw beslissingen voordat de bouw begint; besluiteloosheid is het duurste wat u in een project kunt meebrengen. Ten derde, koppel aan wat u al bezit in plaats van werkende hulpmiddelen te vervangen, en bouw alleen iets opnieuw wanneer het u werkelijk in de weg zit.

Veelgestelde vragen