Naar de inhoud
Elke dinsdag start een nieuwe build.

Algemene voorwaarden

Versie 1.0 · 19 oktober 2026

Versie 1.0 van 19 oktober 2026

Deze voorwaarden gelden voor elke overeenkomst tussen Sounds Global B.V., handelend als AppIn7Dagen, en jou als klant (de Klant). Wij zijn ingeschreven bij de KvK onder nummer 88875539 en gevestigd aan Mariënpoort 12, 8701 XZ Bolsward, Nederland. In deze voorwaarden heten wij verder AppIn7Dagen.

Deze voorwaarden zijn ook in het Engels beschikbaar; de Nederlandse tekst is bindend.

Artikel 1. Begrippen

1.1 Een woord met een hoofdletter dat in de bijlage "Begrippen" staat, betekent wat daar staat. De bijlage hoort bij deze voorwaarden.

1.2 Alle tijden zijn Nederlandse tijd. Een werkdag is maandag tot en met vrijdag, behalve de feestdagen in de feestdagenkalender van het platform. Werkuren zijn 09:00–17:00 op werkdagen.

1.3 Alle bedragen zijn in euro en exclusief btw, tenzij er "incl. btw" bij staat.

Artikel 2. Voor wie

2.1 AppIn7Dagen sluit alleen overeenkomsten met bedrijven en organisaties die handelen in de uitoefening van hun beroep of bedrijf. Nooit met consumenten.

2.2 Je Organisatie legt daarom haar juridische naam, haar KvK-nummer (of het buitenlandse equivalent) en haar adres vast.

2.3 Je eigen inkoopvoorwaarden gelden niet.

Artikel 3. Rangorde

3.1 Spreken documenten elkaar tegen, dan geldt deze volgorde, de hoogste eerst:

  1. dwingend recht;
  2. de getekende afspraken van het Project: de Bouwbrief met zijn Wijzigingen, de verwerkersovereenkomst, de IP-akte en de Fundamental-licentie;
  3. deze algemene voorwaarden.

3.2 Het platform toont je nooit iets dat met deze documenten in strijd is. Gebeurt dat toch, dan gaan deze documenten voor.

Artikel 4. Alles zwart op wit

4.1 Elke afspraak, vraag, beslissing en elk antwoord tussen jou en AppIn7Dagen loopt via het platform op mijn.appin7dagen.nl.

4.2 Alleen Records binden jou en ons. Een e-mail, telefoontje of bericht via een ander kanaal bindt niet.

4.3 Komt er buiten het platform iets bij ons binnen, dan zetten wij het in het Project. Wij vragen je het daar te bevestigen, en handelen pas daarna.

4.4 Wij plannen geen telefoongesprekken of videogesprekken. Vraag je om een gesprek, dan beantwoorden wij je vraag schriftelijk in het platform.

4.5 Een e-mail van ons meldt alleen dat er iets voor jou klaarstaat, en eindigt met een link naar het platform. Een antwoord op zo'n e-mail wordt geen bericht: wij lezen het niet en bewaren het niet.

4.6 Onze streeftijden voor een antwoord op een bericht zijn: 2 werkuren, en 1 werkuur tijdens een Build. Het platform toont de streeftijd bij elk gesprek.

4.7 Overlapt een Storing een termijn die voor jou loopt, dan verlengen wij die termijn met de duur van de Storing. Dat geldt voor:

  1. de stopknop en de feedbackdeadline;
  2. Dag 0;
  3. het automatisch sluiten van een Pin;
  4. je antwoorden in de Bouwcheck;
  5. het vasthouden van de Slot (5.2);
  6. de termijn voor aanvaarding (15.4);
  7. je antwoord op een Blokkerende vraag (10.3).

Wij tellen de verlenging in de eenheid van de termijn: werkuren, werkdagen of gewone uren. Elke verlenging leggen wij vast in een Record. Zou de verlenging het vasthouden van de Slot voorbij haar Start brengen, dan eindigt het bij die Start. Wij bieden je dan de eerstvolgende vrije Slot met voorrang aan, op dezelfde voorwaarden.

Artikel 5. Hoe de overeenkomst ontstaat

5.1 De Bouwcheck is gratis en is ons advies over je Aanvraag. Het is geen aanbod en bindt je nergens aan.

5.2 Is het oordeel Past of Past met aanpassingen, dan krijg je een concept-Bouwbrief. Wij houden de voorgestelde Slot 5 werkdagen voor jou vast.

5.3 Elk lid van je Organisatie kan op elke zin van het concept reageren, en van de specificatie en het brandbook die het vastlegt (9.1). Een aanpassing die daaruit volgt, is een nieuwe versie, zonder kosten. Wij beantwoorden elke reactie. Zolang er een reactie openstaat, kan niemand tekenen.

5.4 Alleen de Beslisser tekent namens jou. Een Beheerder wijst de Beslisser aan. De Beslisser tekent eerst; AppIn7Dagen tekent daarna, binnen 1 werkdag en voordat de Slot vrijvalt.

5.5 Voordat de Beslisser iets tekent, bevestigt die bevoegd te zijn om je organisatie te binden. Die bevestiging staat in het Record.

5.6 De overeenkomst voor een Build ontstaat pas als de Beslisser en AppIn7Dagen allebei de Bouwbrief hebben getekend, en onze betaalprovider de aanbetaling aan ons heeft bevestigd terwijl de Slot nog vrij is. Pas dan is de Slot voor jou gereserveerd.

5.7 Is de Bouwbrief niet binnen de termijn van 5.2 getekend en betaald, dan vervalt hij en komt de Slot vrij. Je kunt dan een nieuwe Bouwbrief met een nieuwe Slot vragen.

5.8 Bij Past met aanpassingen noemt de Bouwcheck voor elk deel buiten de standaardgrenzen een route. Dat is een Uitbreiding in de bouwweek, een Extra sprint met een eigen Slot, een Native app, met de Apple-toeslag waar die geldt, of Doorbouwen na Live. Een Native app is geprijsd naar de Portalen en Uitvoeringen die de Aanvraag noemt. Elke route heeft een prijs en een eerste mogelijke start.

5.9 De specificatie en het brandbook die wij bij de Bouwcheck voor je app opstellen, blijven ons werk tot de IP-akte, die ze met de code aan jou overdraagt. Tot de aanbetaling is betaald, lees je ze alleen in het platform, om ons aanbod te beoordelen en erop te reageren. Je mag ze dan niet kopiëren, delen of gebruiken om de app door een ander te laten bouwen. Elke pagina draagt een watermerk met je Organisatie, je naam en de datum, en wij leggen elke weergave vast in een Record. Na de aanbetaling kun je ze downloaden en gebruik je ze voor de Build.

5.10 Heeft je organisatie nog nooit een aanbetaling gedaan, dan heeft zij hooguit 1 Aanvraag tegelijk open. De volgende kan zodra de Bouwcheck van de vorige is beantwoord en gesloten. Na een aanbetaling geldt die grens niet.

5.11 Is de Slot niet meer vrij als onze betaalprovider je aanbetaling bevestigt, dan betalen wij je hele aanbetaling binnen 14 dagen terug op de oorspronkelijke betaalwijze, met een creditnota. Dat melden wij je in het platform. Je kunt dan een nieuwe Bouwbrief met een nieuwe Slot vragen.

Artikel 6. Elektronisch tekenen

6.1 Je tekent in het platform. Wij zetten de exacte versie van het document om naar een pdf (PDF/A) en berekenen daarvan de SHA-256-hash.

6.2 Tekenen vraagt je eigen passkey, in een bevestiging die alleen voor die versie en die hash geldt. De handtekening voldoet ten minste aan de eIDAS-definitie van een elektronische handtekening, gecombineerd met die sterke authenticatie.

6.3 Het Record van een handtekening bevat de naam, het Account, de rol, de bevoegdheidsverklaring, het tijdstip en de hash van het document. De getekende pdf krijgt een pagina met alle ondertekenaars en de hash. Dat Record is het bewijs van wat is getekend.

6.4 Deze voorwaarden en de Fundamental-licentie teken je niet: je aanvaardt ze per versie, en het Record noemt die versie. Elk document kun je als pdf opslaan voordat je het aanvaardt of tekent.

Artikel 7. Vaste prijs, vaste datum

7.1 De prijs van een Build staat vast in de Bouwbrief. Wij rekenen niet per uur.

7.2 Start, Demo, feedbackdeadline, Testversie en livedatum staan vast in de Bouwbrief, in een tijdschema met echte datums.

7.3 Een datum verschuift alleen door een pauze van de Clock (artikel 10), door een Wijziging, of doordat de Build vóór de Start naar een andere Slot gaat (artikelen 11 en 12). Het platform toont de reden naast elke verschoven datum.

7.4 Extra kosten ontstaan alleen door een getekende Wijziging of door een product dat je apart bestelt.

7.5 Een Wijziging toont wat er verandert tegenover de getekende versie, met het effect op prijs en datums. Zij werkt pas als de Beslisser en AppIn7Dagen haar hebben getekend.

7.6 Tijdens een bouwweek stellen wij geen Wijziging voor die de prijs verhoogt, tenzij je zelf om de verandering vroeg.

Artikel 8. Betaling

8.1 Wij factureren een Build in twee delen: een aanbetaling van 50% van de prijs zodra de Beslisser tekent, en het restant als de Build Live gaat. Nooit eerder. Een Uitbreiding in de bouwweek, een extra koppeling inbegrepen, factureren wij met de Build, in dezelfde twee delen. Een Uitbreiding die een Extra sprint is, heeft een eigen Bouwbrief.

8.2 De betaaltermijn is 7 dagen. Je betaalt in het platform via onze betaalprovider. Abonnementen betaal je per SEPA-incasso; de machtiging ontstaat met een eerste betaling via iDEAL of Wero.

8.3 Op prijzen komt btw. Klanten in Nederland betalen 21% btw. Voor een zakelijke klant in een ander EU-land met een geldig btw-nummer is de btw verlegd. Een zakelijke klant buiten de EU betaalt geen Nederlandse btw, omdat de dienst belast is in het land van de klant. Elk prijsscherm toont het bedrag exclusief btw, met het bedrag inclusief btw ernaast.

8.4 Een verstuurde factuur verandert niet. Een correctie gaat via een creditnota.

8.5 Betaal je niet op tijd, dan sturen wij herinneringen in het platform en per e-mail: 1, 7 en 14 dagen na de vervaldatum.

8.6 Over een te late betaling rekenen wij alleen de wettelijke handelsrente (art. 6:119a BW) en de wettelijke buitengerechtelijke incassokosten. Nooit meer.

8.7 Staat een factuur 30 dagen na de vervaldatum nog open, dan mogen wij de hosting opschorten van de app waar de factuur over gaat. Dat geldt in het Bugvenster, in de periode van 16.4, onder Beheer en onder Doorbouwen. Wij kondigen het 7 dagen vooraf aan, bij doorverkoop ook aan de verwerkingsverantwoordelijke die de verwerkersovereenkomst noemt. Zolang een Fout, gemarkeerd als Blokkerend, op die Build openstaat, schorten wij niet op. Een opgeschorte app bewaren wij, en binnen 1 werkdag nadat elke openstaande factuur is betaald, staat hij weer online. Is de app 30 dagen opgeschort, dan mogen wij onze hosting beëindigen zoals 25.8 tot en met 25.10 zeggen. Je gegevens wissen wij niet omdat je niet betaalt voordat wij de export van 25.8 hebben aangeboden en de termijn van 25.10 voorbij is; tot dan blijft de export van 25.7 beschikbaar.

8.8 Een betaling die uitblijft, is nooit op zichzelf een reden om gegevens van jou te verwijderen. Dat gebeurt pas als onze hosting na een opschorting is geëindigd en de termijn van 25.10 voorbij is.

Artikel 9. Wat je van ons krijgt

9.1 Wij bouwen wat in de Bouwbrief staat. Bij de Bouwcheck stellen wij voor de app twee documenten op: de specificatie en het brandbook. De Bouwbrief legt beide vast met hun versie en digest, en zo horen ze erbij. De specificatie beschrijft de gebruikers en rollen, het Kernproces, de schermen per Portaal, de koppelingen en de data-import; het brandbook bepaalt wat de gebruikers van de app zien. De Bouwbrief noemt de Uitbreidingen. Het doel in de Bouwbrief zegt waarom je de app wilt; of de app klaar is, bepalen de Klaar is als-criteria in de specificatie.

9.2 Elk Klaar is als-criterium in de specificatie is een uitspraak die je met ja of nee beantwoordt door de app te gebruiken.

9.3 Wat op de Niet-lijst staat, bouwen wij niet. Dat is de openbare Niet-lijst plus wat de specificatie eraan toevoegt.

9.4 Je geeft feedback met Pins in de Preview. Of een Pin een Fout of een Wens is, beslissen wij alleen aan de hand van de Klaar is als-criteria. Veranderen wij het type, dan noemen wij het criterium.

9.5 De Beslisser kan een typewijziging betwisten. Een Admin van AppIn7Dagen beslist dan binnen 1 werkdag. De wijziging en de beslissing zijn allebei Records.

9.6 Fouten en Vragen zijn onbeperkt. Per Build tellen hooguit 10 Wensen mee op de Feedbacklijst.

9.7 Is de Feedbacklijst vol, dan geldt de Ruilregel: een nieuwe Wens komt erbij als je een bestaande Wens van gelijke of grotere omvang intrekt. Anders gaat de nieuwe Wens naar de Parkeerlijst.

9.8 Een Wens na de feedbackdeadline (dag 3, 12:00) gaat automatisch naar de Parkeerlijst, en dat hoor je. Een Wens die niet meer in de resterende bouwdagen past, mogen wij met opgave van reden parkeren. Vanaf de Testversie herstellen wij alleen nog Fouten.

9.9 Wensen binnen de Feedbacklijst en de Ruilregel zijn geen Wijzigingen. De Parkeerlijst blijft per Project zichtbaar en gaat mee naar Doorbouwen of een volgende Build.

9.10 Elke Build omvat:

  1. één app die in de browser werkt op computer, tablet en telefoon, gecontroleerd op de formaten van de Preview;
  2. hooguit 2 Portalen, elk met een eigen adres (15.9) en een eigen inlogpagina;
  3. de modules Teksten en beelden, Beheeromgeving en Organisatiebeheer;
  4. hosting in de EU tot het einde van het Bugvenster, behalve bij een Native app (16.5);
  5. de Overdracht;
  6. na volledige betaling: de code en de licentie van artikel 17.

Met Teksten en beelden past je Organisatie elke tekst en elk beeld van de app zelf aan. Met Beheeromgeving beheert je Organisatie de eigen gegevens, lijsten en instellingen, binnen de standaardgrenzen. Met Organisatiebeheer nodigt de eigen beheerder van je Organisatie leden uit, geeft ze hun rollen en verwijdert ze.

9.11 De standaardgrenzen van een Build zijn 10 schermen, 3 rollen, 1 koppeling en 1 importbestand, bij één Kernproces. Wij tellen ze over alle Portalen samen, zodat een tweede Portaal ze niet verdubbelt. Een Extra sprint heeft dezelfde grenzen, geteld over haar nieuwe werk.

9.12 Een Uitbreiding komt uit de gesloten catalogus op onze site. Een Uitbreiding in de bouwweek telt mee voor de standaardgrenzen, en een Build neemt er hooguit 2, een extra koppeling inbegrepen. Wat niet past, wordt een Extra sprint met een eigen Slot en vaste datums.

9.13 Heeft een Uitbreiding een dienst van derden nodig, dan loopt die op je eigen abonnement en in je eigen account, waar de aanbieder dat toelaat. Kan dat niet, dan factureren wij de dienst maandelijks tegen kostprijs, als aparte regel en zonder marge. De aanbieder voldoet aan artikel 20.4.

9.14 Elke Uitbreiding, en elke module uit 9.10, heeft een eerste mogelijke start. De Bouwcheck en de Bouwbrief noemen die, en geen Slot ligt ervoor. Een Uitbreiding die nog niet in onze planning staat, bieden wij niet aan. Is de geplande datum van een Uitbreiding of module voorbij terwijl zij nog niet klaar is, dan tonen wij haar zonder datum. Zolang dat zo is, stellen wij voor een Build die haar bevat geen Slot voor, houden wij er geen vast en reserveren wij er geen. Weten wij wanneer zij klaar is, dan kiezen wij de week.

9.15 Een Native app is een Extra sprint op een Project dat Live is. Zij levert de app, naast de browser, voor de Uitvoeringen die de Bouwbrief per Portaal noemt, op zijn vroegst in de week na de eerste Live van het Project. De specificatie noemt alleen apparaatfuncties die op die Uitvoering bewezen zijn. De prijs bestaat uit stappen: het eerste Portaal op zijn eerste Uitvoering, elke extra Uitvoering op een Portaal, en elk extra Portaal met zijn eerste Uitvoering. Is er meer werk dan één sprint, dan loopt de Native app in twee Native sprints in opeenvolgende Slots, onder één Bouwbrief en één prijs. Is er meer werk dan twee sprints, dan vraagt de Bouwcheck eerst meer informatie.

9.16 Geen prijs omvat een ontwikkelaarsaccount. Voor een Native app heeft je eigen organisatie, op haar eigen naam, een account voor elke genoemde Uitvoering. Dat is het Apple Developer Program voor iOS en macOS, een ontwikkelaarsaccount bij Google Play voor Android en de ondertekeningsidentiteit voor Windows. Je betaalt elk account zelf aan de aanbieder, tegen diens eigen prijs. Noemt een Portaal zo'n Uitvoering, dan controleren wij of het account van je organisatie bestaat. Bestaat het nog niet, dan begeleiden wij je bij de inschrijving, het D-U-N-S-nummer inbegrepen, voordat de Bouwcheck een Slot voorstelt. Die Slot ligt dan ten minste 30 dagen vooruit. Kan je organisatie zich voor een Uitvoering niet inschrijven, dan past die Uitvoering niet.

9.17 Een Project heeft nooit twee Builds tegelijk in de bouw, en nooit een Build naast Doorbouwen. Een Extra sprint kun je tekenen terwijl een eerdere Build nog wordt gebouwd. Zij begint op zijn vroegst als die Build Live is of in het Bugvenster zit.

9.18 De Bouwbrief van een Extra sprint noemt de commit waarop zij voortbouwt. Een Fout beoordelen wij tegen de Bouwbrief waarvan je een Klaar is als-criterium ziet falen.

Artikel 10. Wat wij van jou nodig hebben

10.1 Een Build wordt pas Startklaar als de Dag 0-checklist af is:

  1. de Bouwbrief is door beide partijen getekend en de aanbetaling is betaald;
  2. de testtoegang tot de koppeling is ingevoerd via het geheimenformulier;
  3. Test data of geanonimiseerde voorbeeldbestanden zijn geüpload;
  4. je logo (SVG of PNG) en huiskleuren zijn geüpload;
  5. de verwerkersovereenkomst is getekend, als de live app persoonsgegevens gaat bevatten;
  6. de Beslisser heeft bevestigd op de bouwdagen beschikbaar te zijn;
  7. voor een Native app zijn de ontwikkelaarsaccounts van je eigen organisatie voor elke genoemde Uitvoering geverifieerd.

De deadline is maandag 17:00 vóór de Start.

10.2 Toegangsgegevens geef je alleen via het geheimenformulier, nooit in een bericht of Pin.

10.3 Op bouwdagen beantwoord je een Blokkerende vraag binnen 2 werkuren. Wij stellen zo'n vraag alleen als het werk aan een Klaar is als-criterium zonder antwoord niet verder kan, en noemen wat er vastzit. Nooit om tijd te winnen.

10.4 Blijft je antwoord langer uit, dan pauzeert de Clock tot je antwoordt. Alleen werkuren tellen.

10.5 Pauzes die samen onder de drempel blijven, verschuiven geen datum. Vanaf de drempel schuiven de Testversie en de livedatum op in werkdagen. De drempel en de rekenregel zijn: 4 werkuren; daarboven schuiven de datums 1 dag per 8 gepauzeerde werkuren.

10.6 Je hele Organisatie ziet elke pauze en elke verschoven datum direct, met de vraag erbij. Beide worden vastgelegd in een Record. Een Admin van AppIn7Dagen toetst elke pauze die de livedatum verschuift. Blijkt een vraag niet blokkerend, dan telt haar pauze niet mee en zetten wij de Testversie en de livedatum terug. Je hele Organisatie hoort waarom, in een Record.

Artikel 11. Startdatum verschuift

11.1 Is de Dag 0-checklist niet af op maandag 17:00 vóór de Start, dan verplaatsen wij de Build naar de eerstvolgende vrije Slot. Je aanbetaling blijft staan als tegoed. Dat staat in de Bouwlog.

11.2 Dit gebeurt hooguit 2 keer.

11.3 Daarna kiest de Beheerder in het platform: een Slot vastleggen, of de Build annuleren.

11.4 Annuleert de Beheerder de Build, dan betalen wij je aanbetaling terug, min de kosten die AppIn7Dagen werkelijk voor de Build heeft gemaakt. Wij houden nooit meer in dan € 1.500. Je krijgt een creditnota.

Artikel 12. Wij verschuiven

12.1 Moeten wij een genomen plaats annuleren, bijvoorbeeld door ziekte, dan melden wij dat binnen 1 werkdag in het platform.

12.2 Je kiest dan: de eerstvolgende vrije Slot met voorrang, of de volledige aanbetaling terug.

12.3 Als wij de capaciteit van een week verlagen, annuleert dat nooit een plaats die al genomen is.

12.4 Is de geplande datum van een Uitbreiding voorbij terwijl zij nog niet klaar is (9.14), en is de Slot van haar Build al genomen, dan geldt dat als een annulering door ons onder 12.1. Je kiest dan de eerstvolgende vrije Slot met voorrang, zodra bekend is wanneer de Uitbreiding klaar is, of de volledige aanbetaling terug.

Artikel 13. Demo en stopknop

13.1 Op Dag 2 publiceren wij de Demo. Daarin loopt de Beslisser elke stap van het Kernproces door, van de eerste tot de laatste, op Test data. Elk lid van je Organisatie krijgt bericht.

13.2 Tot dag 3, 09:00 kiest de Beslisser: "Akkoord, bouw door" of de stopknop. Alleen de Beslisser beslist, met sterke authenticatie.

13.3 Beslist de Beslisser niet voor die deadline, dan geldt dat als Akkoord.

13.4 Publiceren wij de Demo door onze vertraging na Dag 2, 17:00, dan verlengen wij de termijn van de stopknop met die vertraging. De livedatum verschuift daardoor niet.

13.5 De stopknop werkt eenmaal per Build, alleen tussen de publicatie van de Demo en de deadline, en niet meer na Akkoord. Stoppen gaat in twee stappen: eerst zie je precies wat er gebeurt, daarna bevestig je.

13.6 Na de stopknop is de Build Gestopt en stopt al ons werk direct. Je krijgt de aanbetaling min de stopvergoeding van € 1.500 binnen 14 dagen terug op de oorspronkelijke betaalwijze, met een creditnota.

13.7 De Preview blijft na een stop 14 dagen alleen-lezen beschikbaar en wordt daarna met de Test data verwijderd. Uploads verwijderen wij binnen 30 dagen. Wat er met de code gebeurt, staat in artikel 18.

13.8 Bij het stoppen doen wij geen aanbiedingen, geven wij geen korting en zetten wij geen druk. Na een stop sturen wij hooguit één bericht met de vraag wat beter had gekund.

13.9 Bij een Native app loopt de Demo via TestFlight, de interne test van Google Play en de installatiebestanden voor de desktop. Pins plaats je op de web-Preview van dezelfde schermen.

Artikel 14. Garantie op de livedatum

14.1 Wij sturen de tweede factuur niet vóór Live.

14.2 Is de Build door onze schuld niet op de livedatum Live, dan werken wij zonder extra kosten door tot Live.

14.3 Tot dat moment draagt de Build het label Te laat, zichtbaar voor je Organisatie.

Artikel 15. Oplevering en acceptatie

15.1 De Build gaat Live op Dag 7, als de releasechecklist en het deel van de Overdracht voor Live compleet zijn. Je Organisatie ziet de releasechecklist. Daarop staan onder meer: elk Klaar is als-criterium gecontroleerd met bewijs, geen open Fout op een criterium, productie in de EU met draaiende back-ups en één uitgevoerde hersteltest, en monitoring aan.

15.2 De Overdracht bevat:

  1. de productie-URL en beheeraccounts voor personen die je noemt;
  2. een gebruikershandleiding per rol, in de taal die je Organisatie voor de Overdracht koos, standaard het Nederlands;
  3. een technische README: architectuur, bouwen, draaien en uitrollen;
  4. uitrolbestanden waarmee je de app zonder AppIn7Dagen elders kunt hosten;
  5. een opgenomen rondleiding van hooguit 15 minuten;
  6. een lijst van diensten van derden, en waar elke toegangssleutel staat (nooit de sleutels zelf);
  7. de gebruikte Fundamental-versie en de licentieverlening;
  8. je Fundamental-kopie, ingericht en gecontroleerd;
  9. de open Parkeerlijst en de einddatum van het Bugvenster.

Punt 1, 2, 5, 6 en 9, en de Fundamental-versie van punt 7, krijg je bij Live, leesbaar in het platform. Punt 3, 4 en 8, en de licentieverlening van punt 7, krijg je met de code als de Build volledig is betaald (17.9).

15.3 Op het moment van Live sturen wij de tweede factuur.

15.4 De Build is aanvaard bij Live. Meldt de Beslisser binnen 5 werkdagen een Fout, gemarkeerd als Blokkerend, tegen een Klaar is als-criterium? Dan volgt de aanvaarding zodra elke zo'n Fout Opgelost is.

15.5 Een Native app is Live als zij via de interne tests van TestFlight en Google Play op de genoemde apparaten te installeren is en ter beoordeling is ingediend. Haar desktopinstallaties zijn dan ondertekend, met een werkende updatebron. Een uitkomst of datum van de beoordeling door een store beloven wij niet; het platform toont de status per store.

15.6 Bij een Native app vervangen de ondertekende builds, met het ondertekeningsmateriaal in je eigen opslag, punt 1 van 15.2. Punt 4 is dan een pijplijn die je op je eigen Mac of CI kunt draaien; die krijg je met de code.

15.7 Voor de beoordeling door Apple en Google maken wij per indiening een demo-Organisatie aan met alleen Test data. Na de indiening trekken wij de inlog van die Organisatie in.

15.8 Een interne app verspreiden wij standaard privé: als niet-openbare app bij Apple en als privé-app bij Google Play, of als custom app via Apple Business Manager. Een openbare vermelding volgt alleen op je verzoek.

15.9 Elk Portaal heeft een adres op onze hosting, onder een domein van AppIn7Dagen dat alleen voor klantapps is. Je kunt elk Portaal op elk moment onder je eigen domein zetten. Wij koppelen een hostnaam pas als een record in je DNS een willekeurige code draagt die bij je Organisatie en die hostnaam hoort. Eindigt onze hosting, dan ontkoppelen wij die hostnaam. Ons adres van je Portaal krijgt nooit een ander Project. Het stuurt nog 12 maanden door naar je eigen adres, zolang je DNS de code nog draagt; anders toont het een pagina dat de app is verhuisd.

Artikel 16. Bugvenster

16.1 Na Live begint het Bugvenster van 30 dagen, behalve bij een Native app (16.5). In die periode herstellen wij Fouten tegen de Bouwbrief kosteloos, binnen de termijnen van artikel 19.3.

16.2 Een Fout die "door termijn" is gesloten, kun je tijdens het Bugvenster heropenen.

16.3 Hosting in productie is inbegrepen tot het einde van het Bugvenster, behalve bij een Native app (16.5). Uiterlijk op dag 20 van het Bugvenster vragen wij de Beheerder te kiezen: Beheer Normaal, Beheer HA, Doorbouwen of zelf hosten. Zelf hosten gaat pas in als de code aan jou is overgedragen (17.9); tot dan geldt die keuze als geen keuze.

16.4 Kies je niet, dan blijft de app nog 30 dagen online, met elke week een melding. Voordat wij de app uitzetten, leveren wij een volledige data-export. Is de code al aan jou overgedragen, dan ook de bijgewerkte uitrolbestanden. Zonder die melding verwijderen wij niets.

16.5 Het Bugvenster van een Native app begint bij de eerste goedkeuring in een store, en uiterlijk 30 dagen na Live. Tot dan blijft de app Live. De hosting van het Project volgt je Beheer of het Bugvenster van de eerdere Build; 16.3 geldt niet.

Artikel 17. Eigendom van de code

17.1 De code van een Build staat in een privé-repository van AppIn7Dagen bij de codehost, tot die Build volledig is betaald. Volledig betaald is: de tweede betaling en de factuur van elke getekende Wijziging, ontvangen en niet meer terug te boeken. Elke Build telt op zichzelf, ook een Extra sprint en een Native app, en de code van een Build gaat pas over als ook elke eerdere Build waarvan het werk erin zit, volledig is betaald. Alleen de Staff van je Project kan die repository openen, in een organisatie met tweestapsverificatie. Tot dan gebruik je de app zoals wij hem hosten, en verspreid je de ondertekende builds van een Native app die wij leverden vanuit je eigen storeaccounts, voor je eigen bedrijf. Dat recht eindigt als onze hosting eindigt na een opschorting onder 8.7.

17.2 Onze codehost-app krijgt alleen schrijfrechten op de app-repositories die je kiest, en leesrechten op metadata. Nooit rechten op je hele organisatie. Je ziet de toegang in het platform en kunt hem altijd intrekken. Wij schrijven daar alleen om code over te dragen, voor een herstel in het Bugvenster, en voor Beheer of Doorbouwen.

17.3 Het auteursrecht en het databankenrecht op de code van je app, en het auteursrecht op de specificatie en het brandbook ervan, draagt AppIn7Dagen aan jou over met de IP-akte. Die akte noemt de repository en de commit die met de code overgaan (17.9), en de versie en digest van beide documenten. Wij tekenen binnen 1 werkdag nadat de code is overgedragen. Daarna tekent de Beslisser. Boekt de betaalprovider of een bank een betaling terug die de akte noemt, dan vallen de overgedragen rechten van rechtswege terug aan AppIn7Dagen. Daarvoor is geen nieuwe akte nodig, en het werkt niet terug in de tijd.

17.4 Vanaf de overdracht van de code tot de IP-akte is getekend, mag je die code gebruiken, wijzigen en laten draaien voor de werking van de app. Het auteursrecht gaat pas met de IP-akte op jou over.

17.5 Fundamental blijft van AppIn7Dagen. Je gebruikt het onder de Fundamental-licentie, voor elke release die je ontving. Releases ontvang je in je Fundamental-kopie, vanaf de overdracht van de code (17.6, 17.9). Die licentie is eeuwigdurend en blijft bestaan als AppIn7Dagen stopt, wordt verkocht of failliet gaat. Dragen wij het auteursrecht op Fundamental over, dan leggen wij de licentie op aan de verkrijger. Zij eindigt alleen zoals de Fundamental-licentie bepaalt.

17.6 Is je eerste Build volledig betaald, dan maak je zelf een Fundamental-kopie in je eigen organisatie bij de codehost. Eerder krijg je geen kopie en geen Leessleutel. Vanaf de overdracht bouwt je app vanaf die kopie. AppIn7Dagen heeft daar nooit schrijftoegang. Trekken wij je Leessleutel in, dan stopt alleen de aanvoer van nieuwe releases; wat er al in staat, blijft bruikbaar.

17.7 Open-sourceonderdelen in je app en in Fundamental vallen onder hun eigen licenties.

17.8 Bij een Native app is elke ondertekeningsidentiteit van jou: aangemaakt in of overgezet naar je eigen accounts en opslag, met Play App Signing aan. Builds voor iOS en macOS maken wij op een Mac die wij in de EU huren voor je Project alleen, onder de licentie van macOS en nooit op een gedeelde virtuele macOS-machine. Wij huren hem alleen zolang er een build voor Apple van je Project wacht of loopt, en beëindigen de huur zodra er geen meer is; elke huur begint met een gewiste Mac. Noemt de Native app op een Portaal iOS of macOS, dan betaalt het Project eenmaal de Apple-toeslag; elk volgend Apple-platform, op welk Portaal ook, kost niets extra. Updatebestanden komen uit je eigen opslag in de EU.

17.9 Is een Build volledig betaald, dan vragen wij je om de Fundamental-kopie van 17.6, als je die nog niet hebt. Binnen 1 werkdag nadat de Build volledig is betaald en je kopie klaarstaat, dragen wij de code over. Je krijgt in het platform de repository met de hele geschiedenis tot de commit die het platform vastlegt, als git-bundel die op elke codehost werkt. Je krijgt er de README en de uitrolbestanden bij. Wil je, dan zetten wij de code ook in een lege privé-repository in je eigen organisatie, met de rechten van 17.2. De laatste commit laat je app vanaf je kopie bouwen. Vooraf controleren wij de hele geschiedenis op geheimen en op code van andere klanten, en de laatste commit op verwijzingen naar onze systemen.

17.10 Na de overdracht doen wij een herstel in het Bugvenster van die Build, Beheer en Doorbouwen in een privé-repository van jou, met de rechten van 17.2. Beheer en Doorbouwen vragen er een; zonder repository leveren wij een herstel in het Bugvenster als git-bundel in het platform. 30 dagen na de overdracht verwijderen wij onze eigen repository van die code, met de kopieën en buildcaches, behalve het werk van een Build die nog niet volledig is betaald. Dat leggen wij vast in een Record.

17.11 Algemene onderdelen blijven van AppIn7Dagen: code die er al was vóór de Build, of die in Fundamental of een kit staat. Vanaf de overdracht van de code mag je ze gebruiken, wijzigen en laten wijzigen als deel van je app, voor altijd. Dat recht is niet-exclusief en gaat mee als je de app, of het bedrijf dat hem bezit, overdraagt. Voor code in Fundamental of een kit gelden daarnaast de grenzen van de Fundamental-licentie.

17.12 Je geeft AppIn7Dagen een kosteloos, niet-exclusief recht om de code van je app te gebruiken en te wijzigen, alleen voor de diensten die je bij ons afneemt en zolang je die afneemt.

Artikel 18. Code na de stopknop

18.1 Drukt de Beslisser op de stopknop, dan krijg je de code van de Build niet. Hij staat in onze repository en blijft van AppIn7Dagen.

18.2 Er volgt dus geen overdracht van code, geen Bugvenster en geen IP-akte. Ook de specificatie en het brandbook blijven ons werk (5.9).

18.3 Binnen 30 dagen na de stop verwijderen wij de code die voor die Build is geschreven, met de kopieën en buildcaches, en leggen dat vast in een Record. Alleen de algemene onderdelen van 17.11 en het werk van een eerdere Build houden wij.

Artikel 19. Beheer en Doorbouwen

19.1 Beheer heeft twee varianten. De Bouwbrief noemt de prijs van elk, en je kiest er één met Beheer (16.3). Beheer Normaal kost € 995 per maand en Beheer HA € 1.795 per maand, elk voor zijn basis van 19.12. Beide omvatten: hosting in de EU; monitoring van binnenuit en van buitenaf, met alarmering; elke 15 minuten een back-up op een tweede plek in de EU; beveiligingsupdates van systeem, containers en afhankelijkheden; Fundamental-upgrades voor beveiligingsfixes; het herstellen van Fouten; en kleine wijzigingen tot 2 uur per maand. Ongebruikte uren vervallen aan het einde van de maand. Je kunt ook een jaar vooruitbetalen: 12 maanden voor de prijs van 11 maanden, als één termijn. Een herstel op een nieuwe server testen en timen wij elk kwartaal onder Beheer Normaal, en elke maand onder Beheer HA, samen met het uitvallen van één server.

19.2 Beveiligingsupdates passen wij toe binnen deze termijnen: 72 uur voor een kritieke kwetsbaarheid en 14 dagen voor een hoge.

19.3 Incidenten en Fouten meld je via het platform. Wij reageren en herstellen binnen deze termijnen per ernst: Kritiek: eerste reactie binnen 1 uur op werkdagen en 4 uur daarbuiten, een workaround binnen 8 uur; Hoog: 4 werkuren en 2 werkdagen; Normaal: 1 werkdag en 5 werkdagen; Laag: 2 werkdagen en de volgende geplande update.

19.4 Een Kritiek incident melden wij in het platform terwijl het loopt. Binnen 5 werkdagen volgt een schriftelijke analyse.

19.5 Wij streven per Portaal naar een beschikbaarheid per maand van 99,5% onder Beheer Normaal en 99,9% onder Beheer HA, van buitenaf gemeten. Gepland onderhoud telt mee. Dat is een inspanningsverplichting. Het platform toont je elke maand de gemeten beschikbaarheid per Portaal. Eén Beheer omvat elk Portaal van het Project.

19.6 Beheer loopt minimaal 3 maanden en is daarna per maand opzegbaar. Beheer kan niet worden gepauzeerd.

19.7 Doorbouwen kost € 7.495 per cyclus van 31 dagen en omvat Beheer Normaal. Met Beheer HA komt het verschil tussen de prijzen van Beheer HA en Beheer Normaal bij elke cyclus, naar rato van haar dagen. Kost de architectuur meer dan de basis, dan komt de toeslag van 19.13 bij elke cyclus. Wij werken aan één Verzoek tegelijk: steeds het bovenste op het Bouwbord. De Beslisser bepaalt de volgorde.

19.8 Een groot Verzoek splitsen wij zichtbaar in delen die elk los te leveren zijn. De meeste Verzoeken staan binnen 2 tot 3 werkdagen in een Preview; dat is een streeftermijn. Heeft je Project een Native app, dan leveren wij een Verzoek op elk platform dat haar Bouwbrief noemt; de beoordeling door een store telt niet mee in die termijn. Na Akkoord van de Beslisser gaat een Verzoek in het eerstvolgende releasevenster naar productie: werkdagen 09:00–16:00, op vrijdag niet na 14:00.

19.9 Een Beheerder kan Doorbouwen pauzeren. De ongebruikte dagen van de lopende cyclus blijven staan. Tijdens de pauze valt de app terug op Beheer, tegen de Beheerprijs van het Project uit 19.1 en 19.13.

19.10 Opzeggen van Doorbouwen werkt aan het einde van de lopende cyclus. Daarna valt de app terug op Beheer als je dat koos; anders geldt artikel 16.4.

19.11 Doorbouwen volgt dezelfde stackregel en dezelfde openbare Niet-lijst als een Build. Alleen een Beheerder bestelt, pauzeert of zegt Beheer en Doorbouwen op.

19.12 De prijs van Beheer Normaal dekt per Project deze basis:

  1. één eigen productieserver zonder bouwhulpmiddelen of hun inloggegevens: elke Build, Extra sprint en Doorbouwen-cyclus draait op een bouwserver die wij daarvoor huren;
  2. op die server de app met een eigen database, geheimenopslag, berichtenbus en telemetrie, op een eigen vast adres dat een vervangende server overneemt;
  3. een deel van een reserveserver die wij klaar houden, en van de bewaking van buitenaf;
  4. 1 TB objectopslag, met een tweede kopie bij een andere aanbieder in de EU;
  5. 20 TB verkeer per maand.

De prijs van Beheer HA dekt per Project: drie eigen productieservers, twee in één datacenter die de app bedienen achter een eigen vast adres en één op een tweede locatie; samen met een eigen database in drie kopieën, geheimenopslag en berichtenbus; een deel van de bewaking van buitenaf; en de punten 1, 4 en 5 hierboven. Geen server, database, opslag of inloggegeven van een Project dient een ander Project of het platform.

19.13 Zijn de gemeten maandelijkse infrastructuurkosten van een Project (C) hoger dan de grens van zijn variant, € 150 onder Beheer Normaal en € 300 onder Beheer HA, dan betaal je de prijs van 19.1 plus het deel van C daarboven, verhoogd met 25%. Bij Doorbouwen komt die toeslag bij elke cyclus, naar rato van haar dagen. Kosten van 9.13 tellen niet mee in C. Een kostenpost die Projecten delen, zoals de reserveserver en de bewaking van buitenaf, telt mee in C gedeeld door 10 Projecten, hoeveel er ook meedelen. Een Project dat meer servers nodig heeft dan zijn variant, betaalt op dezelfde manier. De Bouwbrief noemt vóór ondertekening de prijs van elke variant; C en de toeslag noemt hij alleen als C hoger is dan de grens van Beheer Normaal.

19.14 Wij meten C elke 3 maanden opnieuw uit de facturen van de aanbieders. Je Organisatie krijgt elke regel van C op verzoek, en bij elke nieuwe meting die de prijs verandert. De Beheerprijs uit de Bouwbrief geldt tijdens de minimale looptijd van 19.6. Daarna kondigen wij een hogere prijs 30 dagen vooraf aan in het platform, met elke gewijzigde regel; tot die datum mag je opzeggen. Een lagere prijs geldt vanaf de volgende cyclus.

19.15 Onder Beheer of Doorbouwen halen wij bij een Native app de hersteltijd van 19.3 met een herstel dat bij de store is ingediend of een omweg op de server; de beoordeling door de store telt niet mee. Wij houden de app binnen de jaarlijkse eisen van elke store en vernieuwen haar certificaten. De uren op een gehuurde Mac en het onderhoud in de stores tellen mee in C, onder Beheer en onder Doorbouwen. De Bouwbrief van de Native app noemt de prijs van Beheer of de toeslag op Doorbouwen die volgt uit C met die kosten erin, en C zelf zoals 19.13 zegt. Die gelden vanaf het einde van het Bugvenster van de Native app; latere wijzigingen volgen 19.14. Tot dan dekt de Apple-toeslag de Mac, vanaf de Start van de Native app.

19.16 Valt onder Beheer Normaal de productieserver uit, dan verlies je hooguit 15 minuten aan gegevens. De app staat dan binnen 4 uur weer online, op hetzelfde adres. Onder Beheer HA kost het uitvallen van één server geen vastgelegde gegevens, en werkt de app door of binnen 5 minuten weer. Updates en gepland onderhoud onderbreken een app onder Beheer HA niet. Valt onder Beheer HA de hele eerste locatie uit, dan verlies je hooguit 15 minuten aan gegevens en staat de app binnen 4 uur weer online. Geen van beide varianten belooft beschikbaarheid bij een storing van de hostingaanbieder als geheel, van je eigen DNS of door een fout in een release.

19.17 Een Beheerder kan de variant in het platform wijzigen. Beheer HA geldt vanaf de cyclus nadat de servers in gebruik zijn, en Beheer Normaal vanaf de volgende cyclus na de minimale looptijd van 19.6. De servers van Beheer HA gaan pas in gebruik na een geslaagde test waarin één server uitvalt. Tot dan draait de app onder Beheer Normaal, tegen de prijs van Beheer Normaal.

Artikel 20. Persoonsgegevens

20.1 Een Preview bevat alleen Test data. Upload daarom geen echte persoonsgegevens bij je Aanvraag of voor de Preview. Voorbeeldgegevens laden wij pas in nadat je hebt bevestigd dat ze geanonimiseerd zijn.

20.2 Echte persoonsgegevens komen alleen in de productie-app, en pas nadat de verwerkersovereenkomst is getekend. Wij kopiëren nooit productiegegevens naar een Preview.

20.3 Voor persoonsgegevens in je app, in Previews en in uploads zijn wij verwerker onder de verwerkersovereenkomst (artikel 28 AVG). Voor de gegevens in ons platform zijn wij verwerkingsverantwoordelijke; zie onze privacyverklaring.

20.4 Alle persoonsgegevens, productiegegevens, back-ups, logs, Previews en productie-apps worden opgeslagen en verwerkt in de EU of de EER. Er gelden vier uitzonderingen. Twee betreffen alleen broncode, met de namen en e-mailadressen van auteurs in haar versiegeschiedenis, en de accounts van de mensen die eraan werken. Dat zijn de codehost, een zelfstandige ontvanger en geen subverwerker, onder een adequaatheidsbesluit van de Europese Commissie, en de AI-codeerdiensten uit artikel 21. De derde is de verspreiding, notarisatie, ondertekening en pushberichten van een Native app via Apple, Google en Microsoft, onder je eigen accounts; een pushbericht bevat geen persoonsgegevens. De vierde is onze eigen zakelijke e-mail via Google Workspace, met opslag in Europa, onder eenzelfde adequaatheidsbesluit; die betreft alleen wat jij en wij elkaar per e-mail schrijven. Onze privacyverklaring noemt ze.

20.5 Een datalek dat je Organisatie raakt, melden wij je Organisatie binnen 24 uur nadat het is bevestigd.

Artikel 21. AI bij het bouwen

21.1 Wij mogen AI-codeerdiensten gebruiken op de broncode van je app. Wij gebruiken alleen diensten op onze goedgekeurde lijst, die wij in het platform publiceren en die als subverwerker in onze privacyverklaring staan. Op die lijst staat Claude Code van Anthropic, onder ons contract met Anthropic Ireland, Limited, met verwerking ook in de Verenigde Staten onder de standaardcontractbepalingen van de Europese Commissie. Hun contract verbiedt dat zij de gegevens gebruiken om te trainen. Het laat hen de gegevens standaard hooguit 30 dagen bewaren, en alleen langer voor inhoud die de aanbieder onder zijn gebruiksbeleid markeert of waar de wet dat eist.

21.2 Een AI-dienst krijgt alleen broncode. Persoonsgegevens, productiegegevens, toegangsgegevens en schermafbeeldingen van Pins gaan nooit naar een AI-dienst. De enige uitzondering zijn de namen en e-mailadressen van auteurs in de versiegeschiedenis van die code; een goedgekeurde AI-codeerdienst mag die met de code lezen.

21.3 Elke Build heeft een reviewer van AppIn7Dagen. Die test je app op de Preview en de Testversie zoals je gebruikers dat doen, en meldt de fouten die de ontwikkelaars over het hoofd zagen.

Artikel 22. Geheimhouding

22.1 Jij en AppIn7Dagen houden elkaars vertrouwelijke informatie geheim.

22.2 Vertrouwelijk is informatie die een partij als vertrouwelijk aanmerkt, of waarvan de ontvanger redelijkerwijs moet begrijpen dat zij vertrouwelijk is.

22.3 Niet vertrouwelijk is informatie die openbaar is geworden zonder toedoen van de ontvanger, die de ontvanger al kende of onafhankelijk ontwikkelde, of die hij volgens de wet of een rechter moet openbaren.

22.4 Dat geldt tijdens de overeenkomst en tot 2 jaar nadat zij eindigt.

Artikel 23. Aansprakelijkheid

23.1 De aansprakelijkheid van AppIn7Dagen is per gebeurtenis beperkt tot:

  1. bij een Build: de prijs exclusief btw van de Bouwbrief waar het om gaat;
  2. bij Beheer of Doorbouwen: de vergoedingen van de laatste 12 maanden.

23.2 Nooit meer dan € 100.000 per gebeurtenis.

23.3 AppIn7Dagen is alleen aansprakelijk voor directe schade. Gederfde winst, gemiste besparingen, schade door bedrijfsstagnatie en indirecte schade vergoeden wij niet.

23.4 Het terugzetten van je gegevens uit onze back-ups is directe schade. Die kosten dragen wij.

23.5 De grenzen en de uitsluiting van dit artikel gelden niet bij opzet of bewuste roekeloosheid van de leiding van AppIn7Dagen, en niet waar dwingend recht ze verbiedt.

23.6 Een vordering op AppIn7Dagen vervalt 12 maanden nadat je de feiten waarop zij rust kende, of redelijkerwijs had moeten kennen.

23.7 Voor wat je met de app doet, geldt artikel 30.

Artikel 24. Overmacht

24.1 Overmacht is een omstandigheid buiten de redelijke macht van een partij, die zij redelijkerwijs niet kon voorkomen. Het falen van een leverancier telt mee als dat falen zelf overmacht is.

24.2 Geen overmacht zijn: ziekte of afwezigheid van medewerkers van AppIn7Dagen, gebrek aan capaciteit, en het falen van een leverancier die AppIn7Dagen had kunnen vervangen. Valt een medewerker uit, dan geldt artikel 12.

24.3 Overmacht schort de verplichtingen van een partij op zolang de overmacht duurt.

24.4 Duurt de overmacht 30 dagen, dan mag elke partij de overeenkomst beëindigen die erdoor geraakt wordt. Wat tot dan is geleverd, wordt betaald.

Artikel 25. Zeggenschap en vrij vertrekken

25.1 Is de code aan jou overgedragen (17.9), dan bouwt en draait je app zonder enig systeem van AppIn7Dagen. De app-repository verwijst dan nergens naar onze servers.

25.2 Vanaf dan vraagt weggaan niets van ons: je hoeft niets te verwijderen en ons niets te vragen. De uitrolbestanden uit de Overdracht zijn genoeg om de app elders te hosten.

25.3 Een Beheerder kan alle Records van de Organisatie exporteren als JSON, met wat nodig is om de keten te controleren. Het pdf-dossier per Project sturen wij op verzoek binnen 5 werkdagen.

25.4 Iedere Account-houder kan de eigen gegevens exporteren. Een Beheerder kan de hele Organisatie exporteren.

25.5 Je houdt de volledige zeggenschap over je app. Dat geldt voor je domeinen en voor de gegevens in de app, voor je accounts en abonnementen bij derden, en voor elke beslissing over het product. Na volledige betaling geldt het ook voor de code en de repositories. Je domeinen, accounts en abonnementen staan op je eigen naam.

25.6 AppIn7Dagen host de app vanaf Live, en draait en onderhoudt hem namens jou onder Beheer of Doorbouwen. Is de code aan jou overgedragen, dan houden wij niets achter wat je nodig hebt om de app zonder ons te laten draaien.

25.7 Zolang wij de productiegegevens van je app hebben, kan een Beheerder op elk moment in het platform een volledige export ervan vragen. Dat geldt ook als een factuur openstaat of de app is opgeschort, en het kost niets. Wij leveren de export binnen 2 werkdagen via het platform. Die bevat de database als dump in het PostgreSQL-formaat en de opgeslagen bestanden zoals ze zijn, met een notitie die zegt hoe je ze terugzet.

25.8 Je kunt Beheer opzeggen zoals artikel 19.6 bepaalt, en de app bij elke aanbieder laten hosten. Onze hosting eindigt als je Beheer opzegt, na het Bugvenster zelf gaat hosten, Doorbouwen zonder Beheer opzegt, de dienst na een bezwaar tegen een nieuwe subverwerker beëindigt, overstapt (25.12) of de overeenkomst om overmacht beëindigt. Ook kan zij eindigen na een opschorting onder 8.7. Wij leveren dan vóór de einddatum een vertrekoverdracht. Die bestaat uit een export als in 25.7, gemaakt bij het einde, en de lijst van diensten van derden uit 15.2. Is de code aan jou overgedragen, dan horen er ook de uitrolbestanden en de README bij, bijgewerkt naar de app zoals die draait. Tot de einddatum blijft de app online.

25.9 Binnen 1 werkdag na de einddatum trekken wij de schrijftoegang van onze codehost-app in en verwijderen wij de toegangsgegevens van de app uit onze geheimenopslag. Ook ontkoppelen wij elke hostnaam van je eigen domein (15.9).

25.10 Daarna bewaren wij de productiegegevens nog 30 dagen, ongewijzigd en ongebruikt, zodat je een tweede export kunt vragen. Aan het einde van die termijn verwijderen wij ze, ook uit de back-ups zodra die verlopen, en leggen wij dat vast in een Record. Een Beheerder kan om eerdere verwijdering vragen. Dit geldt ook voor een app die wij onder 16.4 uitzetten.

25.11 Vertrekken kost je niets buiten de vergoedingen tot de einddatum.

25.12 Onze hosting van je app, in het Bugvenster, onder Beheer of Doorbouwen en in de periode van 16.4, is een dienst voor gegevensverwerking in de zin van de Dataverordening (Verordening (EU) 2023/2854). Je kunt daarom altijd vragen om over te stappen naar een andere aanbieder of naar je eigen systemen, of om je gegevens te laten wissen.

25.13 Wij beginnen met de overstap uiterlijk 2 maanden na je verzoek, ook binnen de minimale looptijd van 19.6. Valt de overstap binnen die looptijd, dan betaal je de maanden die er nog van over zijn. Een vooruitbetaald jaar (19.1) betalen wij niet terug.

25.14 Daarna volgt een overgangsperiode van hooguit 30 dagen. Daarin blijft de app online onder deze voorwaarden, tegen de Beheerprijs van het Project uit 19.1 en 19.13, naar rato. Wij helpen jou en je nieuwe aanbieder redelijkerwijs, melden bekende risico's voor de continuïteit en houden de dienst veilig. Je kunt die periode eenmaal verlengen. Is die periode technisch niet haalbaar, dan melden wij dat binnen 14 werkdagen, met de reden en een andere periode van hooguit 7 maanden. De einddatum van 25.8 is het einde van de overgangsperiode.

25.15 Je neemt mee: de volledige export van 25.7 en, als de code aan jou is overgedragen, de code, de uitrolbestanden en de README. Dat is alles wat meegaat. Niet mee gaan onze eigen gegevens over het draaien van de dienst: onze logs, monitoring, geheimen en interne beveiligingsgegevens, en Fundamental buiten de Fundamental-licentie. Op verzoek sturen wij je de procedures, formaten en bekende beperkingen van de export, en de structuur van de gegevens erin. Ook sturen wij op verzoek waar onze infrastructuur staat en wat haar beschermt tegen toegang door overheden buiten de EU.

25.16 Is de overstap klaar, of kies je voor wissen, dan eindigt de overeenkomst voor die dienst en laten wij je dat in het platform weten. Daarna gelden 25.9 en 25.10. Een overstap kost niets buiten de vergoedingen tot de einddatum: wij rekenen geen kosten voor de overstap of voor het meenemen van gegevens.

Artikel 26. Referenties en cases

26.1 Wij tonen je naam, logo, citaten, case of openbare Bouwlog alleen met je toestemming, vastgelegd in een Record. Een Beheerder geeft die toestemming in het platform.

26.2 Met de toestemming voor een case geef je ons een licentie om de case van je bedrijf te tonen: de naam en het logo van je bedrijf en de case van je Build. Die licentie geldt 3 jaar vanaf de publicatie, en je kunt haar in die termijn niet intrekken.

26.3 De naam, foto of het citaat van een persoon en een openbare Bouwlog kun je altijd intrekken. Wij halen die dan binnen 5 werkdagen weg. De case van je bedrijf blijft staan.

26.4 Voor een case krijg je korting: een Build met een case kost € 7.500 in plaats van € 9.500. Dat geldt voor de eerste 3 Builds, en alleen met de vastgelegde toestemming van je Organisatie. Wij tonen geen teller van plaatsen.

26.5 Trek je de naam, foto of het citaat van een persoon of een openbare Bouwlog in, dan houd je de korting. Intrekken kost je niets.

Artikel 27. Partners

27.1 Heeft een Partner je doorverwezen, dan zie je dat in de Aanvraag en in de Bouwbrief, samen met het feit dat de Partner een commissie verdient.

27.2 De commissie is 10% van de prijs van de Build exclusief btw: de prijs van de getekende Bouwbrief en de getekende Wijzigingen, zonder een dienst die wij tegen kostprijs factureren (9.13). Zij is pas verschuldigd nadat je de tweede betaling hebt gedaan. Een Gestopte Build levert geen commissie op.

27.3 Een Partner ziet van je Aanvraag alleen de naam van je Organisatie, de status en de commissie. Niet de Bouwbrief, berichten, Pins of de Preview, tenzij je mensen van de Partner als lid aan je Organisatie toevoegt.

Artikel 28. Wijzigen van deze voorwaarden

28.1 Elke versie van deze voorwaarden heeft een nummer en een datum.

28.2 Een nieuwe versie geldt alleen voor overeenkomsten die na de publicatie ervan worden getekend. Tekenen meer partijen, dan telt de versie die gold bij de eerste handtekening. Een getekende overeenkomst houdt die versie.

28.3 Een lopend abonnement op Beheer of Doorbouwen gaat pas over op een nieuwe versie na een aankondiging in het platform, 30 dagen vooraf. Tot die datum mag je het abonnement opzeggen. Het eindigt dan uiterlijk op die datum, ook binnen de minimale looptijd van artikel 19.6 of de lopende cyclus van artikel 19.10. Tot dan geldt de oude versie.

Artikel 29. Recht en rechter

29.1 Op elke overeenkomst met AppIn7Dagen is Nederlands recht van toepassing.

29.2 Het Weens Koopverdrag (CISG) is uitgesloten.

29.3 Geschillen gaan naar de Rechtbank Noord-Nederland.

Artikel 30. Je verantwoordelijkheid

30.1 Je bent als enige verantwoordelijk en aansprakelijk voor je bedrijfsvoering en voor de inhoud en het gebruik van je app. Dat geldt ook voor de gebruikers van je app en wat je hun belooft, en voor je accounts en abonnementen bij derden.

30.2 Je zorgt dat jij en je app voldoen aan elke wet en elke regel van je sector die voor jou geldt. Voor de persoonsgegevens in je app ben je verwerkingsverantwoordelijke onder de AVG; wij verwerken ze alleen in je opdracht (20.3).

30.3 AppIn7Dagen is niet aansprakelijk voor wat je met de app doet.

30.4 Je vrijwaart AppIn7Dagen voor aanspraken van derden en voor boetes die voortkomen uit wat 30.1 en 30.2 noemen. Dat geldt niet voor zover zij zijn veroorzaakt doordat AppIn7Dagen zelf tekortschoot in de nakoming van haar verplichtingen.

30.5 Dit artikel verandert niets aan de aansprakelijkheid van AppIn7Dagen voor haar eigen werk; die regelt artikel 23. Het sluit geen aansprakelijkheid uit die de wet niet laat uitsluiten.

Bijlage: begrippen

Deze begrippen komen uit de regels van AppIn7Dagen en betekenen overal precies dit.

Bijlage: begrippen
BegripBetekenis
AanvraagJe schriftelijke verzoek om een Build, ingediend via het platform.
AccountEén natuurlijk persoon met één login en één geverifieerd e-mailadres.
AdminDe rol bij AppIn7Dagen die beslist over betwiste Pins en elke pauze toetst die de livedatum verschuift.
AkkoordDe beslissing van de Beslisser na de Demo om door te bouwen.
Apple-toeslagDe eenmalige prijs die een Project betaalt als zijn Native app op een Portaal iOS of macOS noemt, voor de Mac die alleen voor zijn builds voor Apple wordt gehuurd.
BeheerBetaald maandelijks hosten, bewaken, bijwerken en Fouten herstellen van een app die Live is.
BeheerderDe rol in een Organisatie die leden, rollen, facturatie en abonnementen beheert.
BeslisserHet lid van je Organisatie dat voor een Project tekent en de Demo-beslissing neemt.
Blokkerende vraagEen vraag van Staff zonder antwoord waarop de Build niet verder kan. Zij kan de Clock pauzeren.
BouwbordDe rij Verzoeken van een Project na Live.
BouwbriefDe getekende overeenkomst voor één Build. Zij legt de specificatie en het brandbook van de app vast, die samen de omvang zijn, en de datums, prijs en plichten.
BouwcheckOns schriftelijke oordeel over een Aanvraag: Past, Past met aanpassingen, Past niet of Meer info nodig.
BrandbookHet brandbook van de app: hoe de app eruitziet en klinkt. Wij stellen het op bij de Bouwcheck; de Bouwbrief legt het met versie en digest vast.
BouwlogHet gedateerde verslag van wat er in een Build gebeurde, zichtbaar voor de Organisatie.
BugvensterDe periode na Live waarin Fouten binnen de Bouwbrief kosteloos worden hersteld.
BuildDe levering van één Bouwbrief tegen een vaste prijs en omvang, van Start tot Live. Ook: 7-dagen-build.
Build dayDag 1 is de dinsdag van de Slot-week, Dag 2 woensdag, Dag 3 donderdag, Dag 4 vrijdag, Dag 5 zaterdag, Dag 6 zondag, Dag 7 de maandag erna. Dag 0 is elk moment voor Start.
Case met kortingEen Build die wij als case mogen tonen, in ruil voor korting op de prijs (artikel 26).
ClockDe tijdlijn van een Build. Zij loopt vanaf Start en kan pauzeren.
DemoDe versie van de Preview die Staff op Dag 2 als Demo aanwijst.
DoorbouwenEen maandelijks betaald abonnement voor verder bouwen, één Verzoek tegelijk. Omvat Beheer.
FeedbacklijstDe Wensen die meetellen voor de limiet van een Build.
FoutEen Pin die meldt dat de app niet werkt zoals de Bouwbrief zegt.
FundamentalHet eigen Rust-framework van AppIn7Dagen. Elke Build draait erop.
Fundamental-kopieJe eigen privé-kopie van fundamental-dist, in je eigen organisatie bij de codehost, gemaakt na volledige betaling van je eerste Build.
fundamental-distDe repository waarin AppIn7Dagen releases van Fundamental voor klanten publiceert.
GestoptDe status van een Build waarvoor de stopknop is gebruikt.
IP-akteDe akte waarmee het auteursrecht op de code van je app, en op de specificatie en het brandbook ervan, aan jou overgaat.
KernprocesHet kernproces van de Build, als genummerde stappen in de specificatie.
Klaar is alsDe genummerde acceptatiecriteria in de specificatie, elk met ja of nee te beantwoorden.
LeessleutelEen intrekbare, alleen-lezen sleutel per Organisatie waarmee de Fundamental-kopie releases ophaalt.
LidDe rol in een Organisatie zonder beheerrechten.
LiveDe app van de Build draait in productie op onze hosting en het deel van de Overdracht voor Live is geleverd.
Native appDe Extra sprint die de app van een Project, naast de browser, levert voor de Uitvoeringen die elk Portaal noemt, ondertekend met je eigen identiteiten.
Niet-lijstWat een Build uitsluit. De openbare Niet-lijst geldt voor elke Build; de specificatie kan punten toevoegen.
OrganisatieEén klantorganisatie, normaal één rechtspersoon.
OverdrachtHet overdrachtspakket van artikel 15.2: een deel bij Live, de rest met de code na volledige betaling.
ParkeerlijstWensen en ideeën buiten de huidige Build. Zij gaan mee naar Doorbouwen of een volgende Build.
PartnerEen organisatie die klanten doorverwijst onder een Partner-overeenkomst.
PinEen opmerking die je plaatst op een element, gebied of tekst in de Preview: een Fout, Wens of Vraag.
PortaalEen deel van de app van een Project met een eigen adres en een eigen inlogpagina, bijvoorbeeld de app voor je klanten naast de app voor je eigen medewerkers. In het platform heet elk Portaal een app.
PreviewDe werkende versie van je app op Test data, ingebed in het platform.
ProjectEén applicatie die wij voor één Organisatie bouwen of draaien.
RecordEen vermelding in de audittrail van het platform, waarvan elke wijziging aan te tonen is.
RuilregelEen nieuwe Wens boven de limiet komt er alleen bij als je een Wens van gelijke of grotere omvang intrekt.
SlotEen startmoment voor een Build (een dinsdag, 09:00) met een capaciteit.
SpecificatieDe normatieve specificatie van de app: wat de app doet, met de Klaar is als-criteria. Wij stellen haar op bij de Bouwcheck; de Bouwbrief legt haar met versie en digest vast.
StaffEen Account van iemand die voor AppIn7Dagen werkt.
StartDag 1, 09:00.
StopknopHet recht van de Beslisser om na de Demo de Build te beëindigen en de aanbetaling terug te krijgen, min de stopvergoeding.
StoringEen periode van ten minste 120 seconden waarin het platform geen wijziging kon opslaan. Gepland onderhoud is ook een Storing.
Te laatHet label van een Build die door onze schuld niet op de livedatum Live is.
Test dataVerzonnen gegevens die geen echte persoon of echt bedrijf beschrijven.
TestversieDe versie van de Preview die op Dag 4 om 17:00 verschijnt. Vanaf dan komen er geen nieuwe functies meer bij.
UitbreidingEen onderdeel met een vaste prijs buiten het Kernproces, uit de gesloten catalogus, geleverd met een kit.
UitvoeringEen soort apparaat waarvoor een Native app naast de browser wordt geleverd: iPhone en iPad (iOS), Android-telefoons en ‑tablets, Mac (macOS), Windows-pc of Linux.
VerwerkersovereenkomstDe overeenkomst over de persoonsgegevens die wij voor jou verwerken (artikel 28 AVG).
VerzoekEén verzoek binnen Doorbouwen of Beheer.
VraagEen Pin met een vraag.
WensEen Pin die iets anders of iets extra's vraagt dan de Bouwbrief.
WijzigingEen getekende wijziging van een Bouwbrief, ook van de specificatie of het brandbook die zij vastlegt.