API’s hebben pas recent écht de volledige aandacht gekregen van de business. En dat is jammer, want API’s zorgen voor een enorme flexibiliteit in het ontwikkelen van multi-channel producten. Dit artikel zoomt in op de business model opties rondom het ontwikkelen van een succesvolle API strategie.
Achtergrond
Bedrijven die zich in 2022 realiseren dat ze een technologiebedrijf zijn hebben een groot competitief voordeel. Zij zijn bezig gegaan met het afbreken van zogenaamde data-silos: databases met informatie die alleen binnen een specifieke afdeling met een specifieke applicatie kan worden geopend. Misschien hebben ze wat maatwerk software de deur uitgedaan en zijn ze overgestapt op ‘standaard’ ERM, CRP & CRM pakketten, of juist andersom: ze kwamen er achter dat deze standaardoplossingen niet lekker werkten, duur waren en zijn zelf oplossingen gaan bouwen. Hoe dan ook: weg met de data-silo’s: lang leve ‘open data’.
Om het allemaal wat eenvoudiger te maken heb ik een voorbeeld uitgedacht.
De recepten site
We een recepten-website gebouwd. Ooit is deze website als hobby begonnen maar inmiddels zijn er meer dan 15.000 recepten beschikbaar op de website. Maandelijks bezoeken meer dan een miljoen mensen de recepten-database. Er is een succesvolle iPad app. Geld wordt er verdiend door uitgebreide samenwerking met de grote supermarkten. Het team is ongeveer 6 mensen groot, en bevat twee developers die behoorlijk druk zijn met het onderhouden en uitbouwen van de website. Maar – zoals zo vaak – is er ook een hele lijst met nieuwe wensen. De ontwikkelaars kunnen deze wensen niet zo snel bijhouden. De eigenaar heeft met een technische partij om tafel gezeten die haar adviseerde te starten met het bouwen van een API.
Wanneer we nu kijken naar de huidige opzet van het recepten-business model dan zien we dat de waardepropositie wordt gevormd door de recepten. De database met daarin de recepten, is dan ook het kip met de gouden eieren. Het openen van deze database zodat iedereen zijn website aan de recepten-database kan koppelen klinkt niet heel logisch, want hoe voorkom je dat iemand je hele database leeghaalt en zelf een website bouwt?
Het is eenvoudig om via de open data van de overheid een lijst te vinden met alle openbare kunstwerken in Nederland, maar dit is maar voor een beperkte groep mensen écht interessant. Interessanter wordt het zodra de data ook interessante use-cases mogelijk maakt, bijvoorbeeld een API waarmee je de WOZ waarde van een huis kan opvragen door het invoegen van een postcode + huisnummer. Dit is handig voor mensen die op het punt staan om een huis te kopen.
Het weer is ook een uitstekende bron voor een API. Er zijn gespecialiseerde weerdiensten die veel geld vragen voor een data-stroom. Ook beurskoersen doen dit: een abonnement op de niet-vertraagde beurskoersen kost veel geld. Niet zo raar: een API waarmee je direct kunt zien of het gaat waaien stelt bouwers van windmolenparken in staat om goede inschattingen te maken hoeveel energie ze in de toekomst kunnen opwekken. In deze voorbeelden komen al een aantal dingen terug: beschikbaarheid, en ‘live’.
Wanneer is een API strategie nodig? Een API strategie is interesssant eén nodig wanneer een deel van je klant-segmenten ook daadwerkelijk iets kan met jouw nieuwe channel: de API zelf.
Soms is het vanuit regelgeving noodzakelijk om hier over na te denken. Begin dit jaar kregen de banken en financiele instellingen te maken met PSD/2: regulatie om bank-transacties te openen. Iedereen kan hiermee – in theorie – een hele nieuwe interface bouwen rondom jouw banktransacties. Hierdoor wordt de bank veel meer een ‘kabel’.
Terug naar de recepten-website: waarom zou je hier een API van maken? Misschien zijn er maaltijdbezorgers, of supermarkten die hun dienstenaanbod willen uitbreiden. Ze willen graag een geïntegreerde oplossing aanbieden: recepten tonen binnen hun eigen apps. Daarom willen ze graag een API gebruiken: hun ontwikkelaars kunnen via deze koppeling zelf recepten ophalen. En eventueel filteren op ingrediënten die de aanbieder niet zelf heeft. Of om wat voor reden dan ook niet wil tonen, bijvoorbeeld recepten met slechte beoordelingen.
Op het moment dat zo’n klant zich meld dan neemt hij een abonnement op je receptendienst. Je kunt de klant hiervoor op verschillende manieren zakelijk aanvliegen. Hier een aantal opties:
- Eenmalige fee om de API te bouwen
Dit is veruit de slechtste optie: je stuurt eenmalig een rekening van bijvoorbeeld 3 weken ontwikkelwerk om de API te bouwen. Waarom is het een slechte optie? Zodra de klant je API in gebruik heeft genomen zit je vast aan onderhoud: zodra jouw datamodel veranderd moet je valideren of de API nog steeds kloppend is. Voor dit extra werk kun je geen rekeningen sturen.
2. Een maandelijkse fee
Voor SaaS achtige toepassingen is het nuttig om een vast model te rekenen en de API toegang te factureren als zijnde een maandelijks abonnement. Hiermee heb je recurring revenue. Enige is dat je de API wel specifiek toegankelijk moet maken voor een klant, en zodra deze niet meer betaald moet je de API toegang ook in kunnen trekken. Een soort van API sleutel is dus noodzakelijk. Wanneer er meerdere betalende klanten komen voor de API is het ook noodzakelijk te gaan nadenken over documentatie.
3. Een ‘metered’ model
Rolls Royce maakt vliegtuigmotoren. Deze werken ‘metered’. Klanten betalen alleen voor het aantal uren dat ze ‘aan’ zijn. Dit kun je ook doen voor je API. In dit geval: iedere keer dat er via de API een recept wordt opgevraagd betaald de klant €0.002 en iedere keer dat er 1 MB aan afbeeldingen wordt opgevraagd betaald de klant ook iets. Etc. Nadeel hiervan is dat er nogal wat kosten in zitten om dit nauwkeurig door te meten en dat de klanten met lage volumes waarschijnlijk voordelig weg komen. Ook zijn er vanuit klant-zijde allerlei manieren te bedenken om dit model min of meer te omzeilen.
