Terms and conditions

Version 1.0 of 19 October 2026

These terms are written in English; the English text is binding.

These terms apply to every agreement between Sounds Global B.V., trading as AppIn7Days, and you as our client (the Client). We are registered with the Dutch Chamber of Commerce (KvK) under number 88875539, at Mariënpoort 12, 8701 XZ Bolsward, Nederland. In these terms we call ourselves AppIn7Days.

Article 1. Definitions

1.1 A capitalised word listed in the annex "Definitions" means what the annex says. The annex is part of these terms.

1.2 All times are Dutch time. A working day is Monday to Friday, except the public holidays in the platform's holiday calendar. Working hours are 09:00–17:00 on working days.

1.3 All amounts are in euro and exclude VAT, unless marked "incl. VAT".

Article 2. Who we work for

2.1 AppIn7Days only enters into agreements with businesses and organisations acting in the course of their profession or business. Never with consumers.

2.2 Your Organisation therefore records its legal name, its KvK number (or the foreign equivalent) and its address.

2.3 Your own purchase conditions do not apply.

Article 3. Order of precedence

3.1 When documents conflict, this order applies, highest first:

1. mandatory law;
2. the signed agreements of the Project: the Build brief with its Amendments, the data processing agreement, the IP transfer deed and the Fundamental licence;
3. these terms and conditions.

3.2 The platform never shows you anything that contradicts these documents. If it does, these documents prevail.

Article 4. Everything in writing

4.1 Every agreement, question, answer and decision between you and AppIn7Days goes through the platform at my.appin7days.com.

4.2 Only Records bind you and us. An e-mail, a phone call or a message through any other channel does not.

4.3 When something reaches us outside the platform, we copy it into the Project. We ask you to confirm it there, and only then act on it.

4.4 We do not schedule phone or video calls. If you ask for a call, we answer your question in writing in the platform.

4.5 An e-mail from us only tells you something is waiting for you, and ends with a link to the platform. A reply to such an e-mail does not become a message: we do not read it or keep it.

4.6 Our target times for answering a message are: 2 working hours, and 1 during a Build. The platform shows the target next to every thread.

4.7 If an Outage overlaps a deadline running for you, we extend that deadline by the length of the Outage. This applies to:

1. the stop button and the feedback deadline;
2. Day 0;
3. the automatic closing of a Pin;
4. your answers in the Fit check;
5. the hold on the Slot (5.2);
6. the acceptance period (15.4);
7. your answer to a Blocking question (10.3).

We count the extension in the deadline's own unit: working hours, working days or ordinary hours. We record every extension in a Record. If the extension would carry the hold on the Slot past its Start, the hold ends at that Start. We then offer you the next free Slot with priority, on the same terms.

Article 5. How the agreement is formed

5.1 The Fit check is free and is our advice on your Build request. It is not an offer and does not bind you to anything.

5.2 If the verdict is Fits or Fits with changes, you receive a draft Build brief. We hold the proposed Slot for you for 5 working days.

5.3 Every member of your Organisation can comment on any sentence of the draft, and of the specification and brandbook it records (9.1). A change that follows is a new version, at no cost. We answer every comment. While a comment is open, nobody can sign.

5.4 Only the Decision maker signs on your behalf. An Organisation admin appoints the Decision maker. The Decision maker signs first; AppIn7Days signs next, within 1 working day and before the hold on the Slot ends.

5.5 Before the Decision maker signs anything, they confirm that they are authorised to bind your organisation. That confirmation is kept in the Record.

5.6 The agreement for a Build is formed only when the Decision maker and AppIn7Days have both signed the Build brief, and our payment provider has confirmed the deposit while the Slot is still free. Only then is the Slot reserved for you.

5.7 If the Build brief is not signed and paid within the period in 5.2, it expires and the Slot is released. You can then ask for a new Build brief with a new Slot.

5.8 For Fits with changes, the Fit check names a route for every part outside the standard limits. A route is an Add-on in the build week, an Extra sprint with its own Slot, a Native app with the Apple surcharge where it applies, or Keep building after Live. A Native app is priced from the Portals and Editions the Build request names. Each route has a price and a first available start.

5.9 The specification and brandbook we draft for your app with the Fit check remain our work until the IP transfer deed, which passes them to you with the code. Until the deposit is paid, you read them only in the platform, to judge our offer and comment on it. You may not copy them, share them or use them to have the app built by someone else. Every page carries a watermark with your Organisation, your name and the date, and we record every view in a Record. After the deposit you can download them and use them for the Build.

5.10 If your organisation has never paid a deposit, it has at most 1 Build request open at a time. The next can follow once the Fit check on the previous one is answered and closed. After a deposit, that limit does not apply.

5.11 If the Slot is no longer free when our payment provider confirms your deposit, we refund your whole deposit within 14 days to the original payment method, with a credit note. We tell you so in the platform. You can then ask for a new Build brief with a new Slot.

Article 6. Signing electronically

6.1 You sign in the platform. We render the exact version of the document to PDF (PDF/A) and compute its SHA-256 hash.

6.2 Signing requires your own passkey, in a confirmation valid only for that version and that hash. The signature meets at least the eIDAS definition of an electronic signature, combined with that strong authentication.

6.3 The Record of a signature holds the signer's name, Account, role, authority confirmation, the time and the document's hash. The signed PDF gets a page listing every signer and the hash. That Record is the proof of what was signed.

6.4 You do not sign these terms or the Fundamental licence: you accept them by version, and the Record names that version. You can save every document as a PDF before you accept or sign it.

Article 7. Fixed price, fixed dates

7.1 A Build's price is fixed in its Build brief. We never bill by the hour.

7.2 The Start, the Demo, the feedback deadline, the Test version and the Live date are fixed in the Build brief, in a timetable with real dates.

7.3 A date moves only through a pause of the Clock (article 10), through an Amendment, or when the Build moves to another Slot before Start (articles 11 and 12). The platform shows the reason next to every moved date.

7.4 Extra cost arises only from a signed Amendment or from a product you order separately.

7.5 An Amendment shows what changes against the signed version, including its effect on price and dates. It takes effect only once the Decision maker and AppIn7Days have signed it.

7.6 During a build week we do not propose an Amendment that raises the price, unless you asked for the change yourself.

Article 8. Payment

8.1 We invoice a Build in two parts: a deposit of 50% of the price when the Decision maker signs, and the remainder when the Build goes Live. Never earlier. We invoice an Add-on in the build week, an extra integration included, with the Build, in the same two parts. An Add-on that is an Extra sprint has its own Build brief.

8.2 The payment term is 7 days. You pay in the platform through our payment provider. Subscriptions are paid by SEPA Direct Debit; the mandate is created by a first payment through iDEAL or Wero.

8.3 VAT is added to prices. Clients in the Netherlands pay 21% Dutch VAT. For a business client in another EU country with a valid VAT number, the VAT is reverse charged. A business client outside the EU pays no Dutch VAT, because the service is taxed in the client's country. Every price screen shows the amount excluding VAT, with the amount including VAT next to it.

8.4 An issued invoice never changes. A correction goes through a credit note.

8.5 If you do not pay on time, we send reminders in the platform and by e-mail: 1, 7 and 14 days after the due date.

8.6 On late payment we charge only the statutory commercial interest (art. 6:119a BW) and the statutory extrajudicial collection costs. Never more.

8.7 If an invoice is still open 30 days after its due date, we may suspend the hosting of the app the invoice concerns. That holds in the Bug window, in the period of 16.4, under Maintenance and under Keep building. We announce it 7 days in advance, in a resale also to the controller the data processing agreement names. We never suspend while a Bug marked Blocking on that Build is open. We keep a suspended app, and it is back online within 1 working day after every open invoice is paid. Once the app has been suspended for 30 days, we may end our hosting as 25.8 to 25.10 provide. We do not delete your data because you have not paid before we have offered the export of 25.8 and the period of 25.10 has run; until then the export of 25.7 stays available.

8.8 A late payment is never in itself a reason to delete your data. That happens only once our hosting has ended after a suspension and the period of 25.10 has run.

Article 9. What you get from us

9.1 We build what the Build brief describes. With the Fit check we draft two documents for the app: the specification and the brandbook. The Build brief records both with their version and digest, which makes them part of it. The specification describes the users and roles, the core process, the screens per Portal, the integrations and the data import; the brandbook decides what the app's users see. The Build brief names the Add-ons. The goal in the Build brief says why you want the app; whether the app is done is decided by the Done when criteria in the specification.

9.2 Every Done when criterion in the specification is a statement you can answer yes or no by using the app.

9.3 What is on the Not-list, we do not build. That is the public Not-list plus anything the specification adds to it.

9.4 You give feedback with Pins in the Preview. Whether a Pin is a Bug or a Wish is decided only against the Done when criteria. If we change a Pin's type, we name the criterion.

9.5 The Decision maker may dispute a type change. An Admin at AppIn7Days then decides within 1 working day. The change and the decision are both Records.

9.6 Bugs and Questions are unlimited. At most 10 Wishes per Build count towards the Feedback list.

9.7 When the Feedback list is full, the Swap rule applies: a new Wish is added if you withdraw an existing Wish of equal or greater size. Otherwise the new Wish goes to the Parking list.

9.8 A Wish placed after the feedback deadline (Day 3, 12:00) goes to the Parking list automatically, and you are told. A Wish that no longer fits in the remaining build days may be parked by us, with the reason. From the Test version on, we only fix Bugs.

9.9 Wishes within the Feedback list and the Swap rule are not Amendments. The Parking list stays visible per Project and carries over to Keep building or a next Build.

9.10 Every Build includes:

1. one app that works in the browser on desktop, tablet and phone, checked at the Preview's sizes;
2. at most 2 Portals, each with its own address (15.9) and its own sign-in page;
3. the Texts and images, Management area and Organisation management modules;
4. hosting in the EU until the end of the Bug window, except for a Native app (16.5);
5. the Handover;
6. once paid in full: the code and the licence of article 17.

With Texts and images, your Organisation changes any text and image of the app itself. With Management area, your Organisation manages its own records, lists and settings, within the standard limits. With Organisation management, your Organisation's own admin invites members, gives them their roles and removes them.

9.11 A Build's standard limits are 10 screens, 3 roles, 1 integration and 1 import file, with one core process. We count them across all Portals together, so a second Portal does not double them. An Extra sprint has the same limits, counted over its new work.

9.12 An Add-on comes from the closed catalogue on our site. An Add-on in the build week counts towards the standard limits, and a Build takes at most 2 of them, an extra integration included. What does not fit becomes an Extra sprint with its own Slot and fixed dates.

9.13 If an Add-on needs a third-party service, it runs on your own subscription and in your own account, wherever the provider allows it. Where it cannot, we invoice the service monthly at cost, as a separate line and without margin. The provider meets article 20.4.

9.14 Every Add-on, and every module of 9.10, has a first available start. The Fit check and the Build brief name it, and no Slot lies before it. We do not offer an Add-on that is not yet in our planning. If the planned date of an Add-on or module has passed while it is not ready, we show it without a date. While that is so, we do not propose, hold or reserve a Slot for a Build that contains it. Once we know when it is ready, we choose the week.

9.15 A Native app is an Extra sprint on a Project that is Live. It delivers the app, beside the browser, for the Editions the Build brief names for each Portal, at the earliest in the week after the Project's first Live. The specification names only device capabilities proven on that Edition. Its price is made of steps: the first Portal on its first Edition, each further Edition on a Portal, and each further Portal with its first Edition. When the work is more than one sprint, the Native app runs as two Native sprints in consecutive Slots, under one Build brief and one price. When it is more than two sprints, the Fit check first asks for more information.

9.16 No price includes a developer account. For a Native app, your own organisation holds an account in its own name for every Edition named. That is the Apple Developer Program for iOS and macOS, a Google Play developer account for Android, and the code-signing identity for Windows. You pay each account to its provider yourself, at the provider's own price. When a Portal names such an Edition, we check that your organisation's account exists. If it does not exist yet, we guide you through enrolling, the D-U-N-S number included, before the Fit check proposes a Slot. That Slot is then at least 30 days ahead. If your organisation cannot enroll for an Edition, that Edition does not fit.

9.17 A Project never has two Builds in progress at once, and never a Build beside Keep building. You can sign an Extra sprint while an earlier Build is still being built. It starts at the earliest once that Build is Live or in its Bug window.

9.18 The Build brief of an Extra sprint names the commit it builds on. We judge a Bug against the Build brief whose Done when criterion you see failing.

Article 10. What we need from you

10.1 A Build becomes Ready to start only once the Day 0 checklist is complete:

1. the Build brief is signed by both parties and the deposit is paid;
2. test access to the integration is entered through the secret form;
3. Test data or anonymised example files are uploaded;
4. your logo (SVG or PNG) and brand colours are uploaded;
5. the data processing agreement is signed, if the Live app will hold personal data;
6. the Decision maker has confirmed they are available on the build days;
7. for a Native app, your own organisation's developer accounts for every Edition named are verified.

The deadline is Monday 17:00 before Start.

10.2 You give credentials only through the secret form, never in a message or a Pin.

10.3 On build days you answer a Blocking question within 2 working hours. We ask one only when work on a Done when criterion cannot continue without the answer, and we say what is blocked. Never to gain time.

10.4 If your answer takes longer, the Clock pauses until you answer. Only working hours count.

10.5 Pauses that together stay below the threshold move no date. From the threshold on, the Test version and Live dates move by whole working days. The threshold and the rule are: 4 working hours; above it the dates move 1 day per 8 paused working hours.

10.6 Your whole Organisation sees every pause and every moved date at once, linked to its question. Both are kept as Records. An Admin at AppIn7Days reviews every pause that moves the Live date. If a question turns out not to have been blocking, its pause does not count and we restore the Test version and Live dates. Your whole Organisation is told why, in a Record.

Article 11. When your start date moves

11.1 If the Day 0 checklist is not complete by Monday 17:00 before Start, we move the Build to the next free Slot. Your deposit stays with us as credit. The Build log says so.

11.2 This happens at most 2 times.

11.3 After that, the Organisation admin chooses in the platform: fix a Slot, or cancel the Build.

11.4 If the Organisation admin cancels the Build, we refund your deposit minus the costs AppIn7Days actually made for the Build. We never keep more than €1,500. You receive a credit note.

Article 12. When we have to move

12.1 If we have to cancel a place that is taken, for example through illness, we tell you in the platform within 1 working day.

12.2 You then choose: the next free Slot with priority, or a full refund of the deposit.

12.3 Lowering a week's capacity never cancels a place that is already taken.

12.4 If the planned date of an Add-on has passed while it is not ready (9.14), and the Slot of its Build is already taken, that counts as a cancellation by us under 12.1. You then choose the next free Slot with priority, once it is known when the Add-on is ready, or a full refund of the deposit.

Article 13. Demo and stop button

13.1 On Day 2 we publish the Demo. In it, the Decision maker walks every step of the core process, from first to last, on Test data. Every member of your Organisation is notified.

13.2 Until Day 3, 09:00 the Decision maker chooses: "Approve, keep building" or the stop button. Only the Decision maker decides, with strong authentication.

13.3 If the Decision maker makes no decision before that deadline, it counts as Approved.

13.4 If our delay means the Demo is published after Day 2, 17:00, we extend the stop button window by that delay. The Live date does not move because of it.

13.5 The stop button works once per Build, only between the Demo's publication and the deadline, and not after Approved. Stopping takes two steps: first you see exactly what will happen, then you confirm.

13.6 After the stop button, the Build is Stopped and all our work stops at once. You get the deposit back minus the stop fee of €1,500, within 14 days, to the original payment method, with a credit note.

13.7 After a stop, the Preview stays available read-only for 14 days and is then deleted with its Test data. We delete uploads within 30 days. What happens to the code is in article 18.

13.8 When you stop, we make no offers, give no discounts and apply no pressure. After a stop we send at most one message asking what could have been better.

13.9 For a Native app, the Demo runs through TestFlight, Google Play's internal testing and the desktop installers. You place Pins on the web Preview of the same screens.

Article 14. Live date guarantee

14.1 We do not send the second invoice before Live.

14.2 If the Build is not Live on its Live date through our fault, we keep working at no extra cost until it is.

14.3 Until then, the Build carries the label Late, visible to your Organisation.

Article 15. Delivery and acceptance

15.1 The Build goes Live on Day 7, once the release checklist and the Handover's part for Live are complete. Your Organisation sees the release checklist. It includes: every Done when criterion checked with evidence, no open Bug on any criterion, production in the EU with backups running and one restore tested, and monitoring switched on.

15.2 The Handover contains:

1. the production URL and admin accounts for people you name;
2. a user guide for each role, in the language your Organisation chose for the Handover, English by default;
3. a technical README: architecture, and how to build, run and deploy;
4. deployment files that let you host the app elsewhere without AppIn7Days;
5. a recorded walkthrough of at most 15 minutes;
6. a list of third-party services, and where each credential is stored (never the credentials themselves);
7. the Fundamental version used and the licence grant;
8. your Fundamental mirror, set up and verified;
9. the open Parking list and the end date of the Bug window.

You receive items 1, 2, 5, 6 and 9, and the Fundamental version of item 7, at Live, readable in the platform. You receive items 3, 4 and 8, and the licence grant of item 7, with the code once the Build is paid in full (17.9).

15.3 At the moment the Build goes Live, we send the second invoice.

15.4 The Build is accepted at Live. Does the Decision maker file a Bug marked as blocking against a Done when criterion within 5 working days? Then acceptance follows once every such Bug is Resolved.

15.5 A Native app is Live when it can be installed on the named devices through TestFlight's and Google Play's internal testing and has been submitted for review. Its desktop installers are then signed, with a working update feed. We do not promise a review outcome or date from any store; the platform shows each store's status.

15.6 For a Native app, the signed builds, with the signing material in your own storage, replace item 1 of 15.2. Item 4 is then a pipeline you can run on your own Mac or CI; you receive it with the code.

15.7 For review by Apple and Google, we create a demo Organisation with Test data only for each submission. After the submission we revoke that Organisation's sign-in.

15.8 We distribute an internal app privately by default: as an unlisted app with Apple and a private app on Google Play, or as a custom app through Apple Business Manager. A public listing follows only at your request.

15.9 Every Portal has an address on our hosting, under a domain of AppIn7Days that is for client apps only. You can put any Portal under your own domain at any time. We bind a hostname only once a record in your DNS carries a random code that belongs to your Organisation and that hostname. When our hosting ends, we unbind that hostname. Our address of your Portal never goes to another Project. It redirects to your own address for 12 more months while your DNS still carries the code; otherwise it shows a page saying the app has moved.

Article 16. Bug window

16.1 At Live the Bug window of 30 days begins, except for a Native app (16.5). During it, we fix Bugs against the Build brief free of charge, within the times of article 19.3.

16.2 A Bug closed "by deadline" can be reopened during the Bug window.

16.3 Production hosting is included until the end of the Bug window, except for a Native app (16.5). By day 20 of the Bug window, we ask the Organisation admin to choose: Maintenance Normal, Maintenance HA, Keep building or hosting it yourself. Hosting it yourself takes effect only once the code has passed to you (17.9); until then, that choice counts as no choice.

16.4 If you do not choose, the app stays online for 30 days more, with a notice every week. Before we switch it off, we deliver a full data export. If the code has already passed to you, we also deliver the deployment files, brought up to date. Nothing is deleted without that notice.

16.5 A Native app's Bug window starts at its first store approval, and at the latest 30 days after Live. Until then the app stays Live. The Project's hosting follows your Maintenance or the earlier Build's Bug window; 16.3 does not apply.

Article 17. Ownership of the code

17.1 A Build's code lives in a private repository of AppIn7Days on the code host until that Build is paid in full. Paid in full means: the second payment and the invoice of every signed Amendment, received and no longer reversible. Each Build counts on its own, an Extra sprint and a Native app included, and a Build's code passes only once every earlier Build whose work it holds is paid in full too. Only your Project's Staff can open that repository, in an organisation that enforces two-factor sign-in. Until then you use the app as we host it, and distribute from your own store accounts the signed builds of a Native app we delivered, for your own business. That right ends when our hosting ends after a suspension under 8.7.

17.2 Our code-host app only gets write access to the app repositories you select, and read access to metadata. Never rights over your whole organisation. You see the grant in the platform and can revoke it at any time. We write there only to pass code to you, for a fix in the Bug window, and for Maintenance or Keep building.

17.3 AppIn7Days transfers to you the copyright and database right in your app's code, and the copyright in its specification and brandbook, by the IP transfer deed. The deed names the repository and the commit that pass with the code (17.9), and the version and digest of both documents. We sign within 1 working day after the code has passed. The Decision maker signs next. If the payment provider or a bank reverses a payment the deed recites, the transferred rights revert to AppIn7Days by operation of law. That needs no new deed, and it has no retroactive effect.

17.4 From the moment the code passes to you until the IP transfer deed is signed, you may use, change and run that code for running the app. The copyright passes to you only by the IP transfer deed.

17.5 Fundamental remains AppIn7Days'. You use it under the Fundamental licence, for every release you received. You receive releases in your Fundamental mirror, from the moment the code passes (17.6, 17.9). That licence is perpetual and survives AppIn7Days stopping, being sold or going bankrupt. If we transfer the copyright in Fundamental, we impose the licence on the acquirer. It ends only as the Fundamental licence provides.

17.6 Once your first Build is paid in full, you create your own Fundamental mirror in your own organisation on the code host. You get no mirror and no Read key before then. From the moment the code passes, your app builds from that mirror. AppIn7Days never has write access to it. If we revoke your Read key, only new releases stop arriving; everything already in the mirror stays usable.

17.7 Open-source components in your app and in Fundamental are covered by their own licences.

17.8 For a Native app, every signing identity is yours: generated in or moved to your own accounts and storage, with Play App Signing on. We make iOS and macOS builds on a Mac we lease in the EU for your Project alone, under the macOS licence and never on a shared macOS virtual machine. We lease it only while an Apple build of your Project is waiting or running, and end the lease once none is; every lease starts from a wiped Mac. When the Native app names iOS or macOS on any Portal, the Project pays the Apple surcharge once; every further Apple platform, on any Portal, adds nothing. Update files are served from your own storage in the EU.

17.9 Once a Build is paid in full, we ask you for the Fundamental mirror of 17.6, if you do not have one yet. Within 1 working day after the Build is paid in full and your mirror is ready, we pass its code to you. In the platform you receive the repository with its whole history up to the commit the platform records, as a git bundle that works on any code host. With it come the README and the deployment files. If you wish, we also put the code in an empty private repository in your own organisation, with the rights of 17.2. The last commit makes your app build from your mirror. Before that, we check the whole history for secrets and for any other client's code, and the last commit for references to our systems.

17.10 After the code has passed, we do a fix in that Build's Bug window, Maintenance and Keep building in a private repository of yours, with the rights of 17.2. Maintenance and Keep building need one; without a repository we deliver a Bug window fix as a git bundle in the platform. 30 days after the code has passed, we delete our own repository of it, with its clones and build caches, except the work of a Build not yet paid in full. We keep a Record of it.

17.11 Generic components stay AppIn7Days': code that existed before the Build, or that lives in Fundamental or a kit. From the moment the code passes, you may use them, change them and have them changed as part of your app, for ever. That right is non-exclusive and passes with the app when you transfer the app, or the business that owns it. For code in Fundamental or a kit, the limits of the Fundamental licence apply as well.

17.12 You give AppIn7Days a free, non-exclusive right to use and change your app's code, only for the services you buy from us and for as long as you buy them.

Article 18. Code after the stop button

18.1 If the Decision maker presses the stop button, you do not receive the Build's code. It is in our repository and stays AppIn7Days'.

18.2 So no code passes, and there is no Bug window and no IP transfer deed. The specification and brandbook stay our work too (5.9).

18.3 Within 30 days of the stop, we delete the code written for that Build, with its clones and build caches, and keep a Record of it. We keep only the generic components of 17.11 and the work of an earlier Build.

Article 19. Maintenance and Keep building

19.1 Maintenance comes in two tiers. The Build brief states the price of each, and you choose one with Maintenance (16.3). Maintenance Normal costs €995 per month and Maintenance HA €1,795 per month, each for its baseline of 19.12. Both include: hosting in the EU; monitoring from inside and outside, with alerting; a backup every 15 minutes in a second location in the EU; security updates of the system, containers and dependencies; Fundamental upgrades for security fixes; fixing Bugs; and small changes up to 2 hours per month. Unused hours lapse at the end of the month. You can also prepay a year: 12 months for the price of 11 months, as one term. We test and time a restore onto a new server every quarter under Maintenance Normal, and every month under Maintenance HA, together with the failure of one server.

19.2 We apply security updates within these times: 72 hours for a critical vulnerability and 14 days for a high one.

19.3 You report incidents and Bugs through the platform. We respond and fix within these times per severity: Critical: first response within 1 hour on working days and 4 hours outside, a workaround within 8 hours; High: 4 working hours and 2 working days; Normal: 1 working day and 5 working days; Low: 2 working days and the next planned update.

19.4 We report a Critical incident in the platform while it runs. A written post-mortem follows within 5 working days.

19.5 For each Portal we aim for an availability per month of 99.5% under Maintenance Normal and 99.9% under Maintenance HA, measured from outside. Planned maintenance counts. This is a best-efforts obligation. The platform shows you the measured availability of each Portal every month. One Maintenance covers every Portal of the Project.

19.6 Maintenance runs for at least 3 months, and can then be cancelled monthly. Maintenance cannot be paused.

19.7 Keep building costs €7,495 per cycle of 31 days and includes Maintenance Normal. With Maintenance HA, the difference between the prices of Maintenance HA and Maintenance Normal is added to each cycle, pro rata to its days. If the architecture costs more than the baseline, the surcharge of 19.13 is added to each cycle. We work on one Request at a time: always the top one on the Build board. The Decision maker sets the order.

19.8 We split a large Request, visibly, into parts that can each be delivered on their own. Most Requests reach a Preview within 2 to 3 working days; that is a target. If your Project has a Native app, we deliver a Request on every platform its Build brief names; a store's review does not count in that time. After the Decision maker's approval, a Request goes to production in the next release window: working days 09:00–16:00, not on Friday after 14:00.

19.9 An Organisation admin can pause Keep building. The unused days of the running cycle are kept. During the pause the app falls back to Maintenance, at the Project's Maintenance price under 19.1 and 19.13.

19.10 Cancelling Keep building takes effect at the end of the running cycle. The app then falls back to Maintenance if you chose it; otherwise article 16.4 applies.

19.11 Keep building follows the same stack rule and the same public Not-list as a Build. Only an Organisation admin orders, pauses or cancels Maintenance and Keep building.

19.12 The price of Maintenance Normal covers this baseline per Project:

1. one production server of its own, without build tooling or its credentials: every Build, Extra sprint and Keep building cycle runs on a build server we rent for it;
2. on that server, the app with its own database, secrets store, message bus and telemetry, at a fixed address of its own that a replacement server takes over;
3. a share of a spare server we keep ready, and of the watch from outside;
4. 1 TB of object storage, with a second copy at another provider in the EU;
5. 20 TB of traffic per month.

The price of Maintenance HA covers per Project: three production servers of its own, two in one data centre serving the app behind a fixed address of its own and one in a second location; together with its own database in three copies, secrets store and message bus; a share of the watch from outside; and items 1, 4 and 5 above. No server, database, storage or credential of a Project serves another Project or the platform.

19.13 If a Project's measured monthly infrastructure cost (C) exceeds the limit of its tier, €150 under Maintenance Normal and €300 under Maintenance HA, you pay the price of 19.1 plus the part of C above it, increased by 25%. Under Keep building that surcharge is added to each cycle, pro rata to its days. Costs under 9.13 do not count in C. A cost that Projects share, such as the spare server and the watch from outside, counts in C divided by 10 Projects, however many share it. A Project that needs more servers than its tier pays the same way. The Build brief states the price of each tier before signing; it states C and the surcharge only if C exceeds the limit of Maintenance Normal.

19.14 We re-measure C every 3 months from the providers' invoices. Your Organisation receives every line of C on request, and with every new measurement that changes the price. The Maintenance price in the Build brief holds for the minimum term of 19.6. After it, we announce a higher price in the platform 30 days before it applies, with every changed line; until that date you may cancel. A lower price applies from the next cycle.

19.15 Under Maintenance or Keep building, for a Native app we meet the fix time of 19.3 with a fix submitted to the store or a workaround on the server; the store's review does not count. We keep the app within each store's yearly requirements and renew its certificates. The hours on a leased Mac and the upkeep in the stores count in C, under Maintenance and under Keep building. The Native app's Build brief states the Maintenance price or Keep building surcharge that follows from C with those costs in it, and C itself as 19.13 says. They apply from the end of the Native app's Bug window; later changes follow 19.14. Until then the Apple surcharge covers the Mac, from the Native app's Start.

19.16 If the production server fails under Maintenance Normal, you lose at most 15 minutes of data. The app is then back online within 4 hours, at the same address. Under Maintenance HA, the failure of one server costs no committed data, and the app keeps working or works again within 5 minutes. Updates and planned maintenance do not interrupt an app under Maintenance HA. If the whole first location fails under Maintenance HA, you lose at most 15 minutes of data and the app is back online within 4 hours. Neither tier promises availability through a failure of the hosting provider as a whole, of your own DNS, or caused by a defect in a release.

19.17 An Organisation admin can change the tier in the platform. Maintenance HA applies from the cycle after its servers are in service, and Maintenance Normal from the next cycle after the minimum term of 19.6. The servers of Maintenance HA go into service only after a passed test in which one server fails. Until then the app runs under Maintenance Normal, at the price of Maintenance Normal.

Article 20. Personal data

20.1 A Preview holds Test data only. So do not upload real personal data with your Build request or for the Preview. We load example data only after you confirm it is anonymised.

20.2 Real personal data enters only the production app, and only after the data processing agreement is signed. We never copy production data into a Preview.

20.3 For personal data in your app, in Previews and in uploads, we are processor under the data processing agreement (article 28 GDPR). For the data in our platform we are controller; see our privacy statement.

20.4 All personal data, production data, backups, logs, Previews and production apps are stored and processed in the EU or EEA. There are four exceptions. Two cover only source code, with the author names and e-mail addresses in its version history, and the accounts of the people who work on it. They are the code host, an independent recipient and not a sub-processor, under an adequacy decision of the European Commission, and the AI coding services of article 21. The third is a Native app's distribution, notarisation, signing and push messages through Apple, Google and Microsoft, under your own accounts; a push message holds no personal data. The fourth is our own business e-mail through Google Workspace, with its data stored in Europe, under the same kind of adequacy decision; it covers only what you and we write to each other by e-mail. Our privacy statement names them.

20.5 We report a personal data breach affecting your Organisation to your Organisation within 24 hours of confirming it.

Article 21. AI in building

21.1 We may use AI coding services on your app's source code. We use only services on our approved list, which we publish in the platform and which our privacy statement lists as sub-processors. That list holds Claude Code by Anthropic, under our contract with Anthropic Ireland, Limited, with processing also in the United States under the European Commission's standard contractual clauses. Their contract forbids them to train on the data. It lets them keep the data for at most 30 days as standard, and longer only for content the provider flags under its usage policy or where the law requires it.

21.2 An AI service receives source code only. Personal data, production data, credentials and Pin screenshots are never sent to an AI service. The one exception is the author names and e-mail addresses in that code's version history, which an approved AI coding service may read with the code.

21.3 Every Build has an AppIn7Days reviewer, who tests your app on the Preview and the Test version the way your users will, and reports the bugs the developers missed.

Article 22. Confidentiality

22.1 You and AppIn7Days keep each other's confidential information confidential.

22.2 Confidential information is information a party marks as confidential, or that the receiving party should reasonably understand to be confidential.

22.3 Information is not confidential if it became public other than through the receiving party, was already known to it, was developed by it independently, or must be disclosed by law or a court.

22.4 This applies during the agreement and for 2 years after it ends.

Article 23. Liability

23.1 AppIn7Days' liability per event is limited to:

1. for a Build: the price, excluding VAT, of the Build brief concerned;
2. for Maintenance or Keep building: the fees of the last 12 months.

23.2 Never more than €100,000 per event.

23.3 AppIn7Days is liable for direct damage only. We do not pay for lost profit, lost savings, damage from business interruption or indirect damage.

23.4 Restoring your data from our backups is direct damage. We bear that cost.

23.5 The limits and the exclusion in this article do not apply to intent or deliberate recklessness of AppIn7Days' management, nor where mandatory law forbids them.

23.6 A claim against AppIn7Days lapses 12 months after you knew, or should reasonably have known, the facts it rests on.

23.7 For what you do with the app, article 30 applies.

Article 24. Force majeure

24.1 Force majeure is a circumstance beyond a party's reasonable control that it could not reasonably prevent. A supplier's failure counts when that failure is itself force majeure.

24.2 Not force majeure: illness or absence of AppIn7Days' own staff, a lack of capacity, and the failure of a supplier AppIn7Days could have replaced. If a staff member drops out, article 12 applies.

24.3 Force majeure suspends a party's duties for as long as it lasts.

24.4 Once force majeure has lasted 30 days, either party may end the agreement it affects. What was delivered until then is paid for.

Article 25. Control and free to leave

25.1 Once the code has passed to you (17.9), your app builds and runs without any AppIn7Days system. The app repository then contains no reference to our servers.

25.2 From then on, leaving needs nothing from us: you need not uninstall anything or ask us for anything. The deployment files from the Handover are enough to host the app elsewhere.

25.3 An Organisation admin can export all of the Organisation's Records as JSON, with what is needed to verify the chain. We send the PDF dossier per Project on request within 5 working days.

25.4 Every Account holder can export their own data. An Organisation admin can export the whole Organisation.

25.5 You keep full control of your app. That covers your domains and the data in the app, your accounts and subscriptions with third parties, and every decision about the product. Once paid in full, it also covers the code and the repositories. Your domains, accounts and subscriptions are held in your own name.

25.6 AppIn7Days hosts the app from Live, and runs and maintains it on your behalf under Maintenance or Keep building. Once the code has passed to you, we hold back nothing you need to run the app without us.

25.7 While we hold your app's production data, an Organisation admin can ask in the platform for a full export of it at any time. That holds while an invoice is open or the app is suspended too, and it costs nothing. We deliver the export within 2 working days through the platform. It holds the database as a dump in the PostgreSQL format and the stored files as they are, with a note that says how to restore them.

25.8 You can cancel Maintenance as article 19.6 provides, and have the app hosted by any provider. Our hosting ends when you cancel Maintenance, host the app yourself after the Bug window, cancel Keep building without Maintenance, end the service after objecting to a new sub-processor, switch (25.12) or end the agreement for force majeure. It may also end after a suspension under 8.7. We then deliver an exit handover before the end date. It consists of an export as in 25.7, made at the end, and the list of third-party services of 15.2. If the code has passed to you, it also holds the deployment files and the README, brought up to date with the app as it runs. The app stays online until the end date.

25.9 Within 1 working day after the end date we remove our code-host app's write access and delete the app's credentials from our secrets store. We also unbind every hostname of your own domain (15.9).

25.10 We then keep the production data for 30 days more, unchanged and unused, so you can ask for a second export. At the end of that period we delete it, from the backups too as they expire, and keep a Record of the deletion. An Organisation admin can ask for earlier deletion. This also applies to an app we switch off under 16.4.

25.11 Leaving costs you nothing beyond the fees up to the end date.

25.12 Our hosting of your app, in the Bug window, under Maintenance or Keep building and in the period of 16.4, is a data processing service under the Data Act (Regulation (EU) 2023/2854). You may therefore ask at any time to switch to another provider or to your own systems, or to have your data erased.

25.13 We start the switch no later than 2 months after your request, also within the minimum term of 19.6. If the switch falls within that term, you pay the months of it that remain. We do not refund a prepaid year (19.1).

25.14 A transitional period of at most 30 days then follows. During it the app stays online under these terms, at the Project's Maintenance price under 19.1 and 19.13, pro rata. We give you and your new provider reasonable help, report known risks to continuity and keep the service secure. You may extend that period once. If that period is technically not feasible, we tell you within 14 working days, with the reason and another period of at most 7 months. The end date of 25.8 is the end of the transitional period.

25.15 You take with you: the full export of 25.7 and, once the code has passed to you, the code, the deployment files and the README. That is everything that moves. What does not move is our own data about running the service: our logs, monitoring, secrets and internal security data, and Fundamental beyond the Fundamental licence. On request we send you the export's procedures, formats and known limitations, and the structure of the data in it. On request we also send you where our infrastructure is and what protects it against access by authorities outside the EU.

25.16 Once the switch is complete, or you choose erasure, the agreement for that service ends and we tell you so in the platform. Then 25.9 and 25.10 apply. A switch costs nothing beyond the fees up to the end date: we charge nothing for switching or for taking your data with you.

Article 26. References and cases

26.1 We show your name, logo, quotes, case or public Build log only with your consent, kept as a Record. An Organisation admin gives that consent in the platform.

26.2 With the consent to a case, you give us a licence to show your company's case: your company's name and logo and the case of your Build. That licence runs for 3 years from publication, and you cannot withdraw it within that term.

26.3 You can withdraw a person's name, photo or quote, and a public Build log, at any time. We then remove it within 5 working days. Your company's case stays.

26.4 For a case, you get a discount: a Build with a case costs €7,500 instead of €9,500. This applies to the first 3 Builds, and only with your Organisation's recorded consent. We show no counter of places.

26.5 If you withdraw a person's name, photo or quote, or a public Build log, you keep the discount. Withdrawing costs you nothing.

Article 27. Partners

27.1 If a Partner referred you, you see this in the Build request and in the Build brief, together with the fact that the Partner earns a commission.

27.2 The commission is 10% of the Build price excluding VAT: the price of the signed Build brief and the signed Amendments, without any service we invoice at cost (9.13). It becomes due only after you have made the second payment. A Stopped Build earns no commission.

27.3 Of your Build request, a Partner sees only your Organisation's name, its status and the commission. Not the Build brief, messages, Pins or the Preview, unless you add the Partner's people as members of your Organisation.

Article 28. Changes to these terms

28.1 Every version of these terms has a number and a date.

28.2 A new version applies only to agreements signed after its publication. When more than one party signs, the version in force at the first signature counts. A signed agreement keeps that version.

28.3 A running subscription to Maintenance or Keep building moves to a new version only after notice in the platform, 30 days in advance. Until that date, you may cancel the subscription. It then ends no later than that date, even within the minimum term of article 19.6 or the running cycle of article 19.10. The old version applies until then.

Article 29. Law and court

29.1 Every agreement with AppIn7Days is governed by Dutch law.

29.2 The Vienna Sales Convention (CISG) is excluded.

29.3 Disputes go to the Rechtbank Noord-Nederland.

Article 30. Your responsibility

30.1 You alone are responsible and liable for your business conduct and for the content and use of your app. The same goes for your app's users and what you promise them, and for your accounts and subscriptions with third parties.

30.2 You make sure that you and your app comply with every law and every rule of your sector that applies to you. For the personal data in your app you are the controller under the GDPR; we process it only on your instructions (20.3).

30.3 AppIn7Days is not liable for what you do with the app.

30.4 You indemnify AppIn7Days against claims of third parties and against fines that arise from what 30.1 and 30.2 name. This does not apply to the extent they are caused by AppIn7Days' own failure to perform its obligations.

30.5 This article changes nothing in AppIn7Days' liability for its own work, which article 23 governs. It excludes no liability the law does not allow to be excluded.

Annex: definitions

These terms come from AppIn7Days' rules and mean exactly this wherever they appear.