The details you choose and pay for sit in the accepted order (and any accepted proposal or statement of work it points to), and the terms below explain how we run the work day to day.
If the order and these terms ever say different things about the same point, the order wins. Everything else is handled under these terms so both sides know what to expect before we start.
Your order is the short summary that sits on top of these terms. It is where we list what you are buying (SaaS product build), the start date, the retainer amount, what the retainer covers each month, and any one-off setup or launch budget.
We use the order to remove guesswork: it is the source of truth for price, timing, and what is included for the current term. If something matters to you and it is not written in the order or the proposal the order points to, it is not agreed yet. If the order and these terms clash, follow the order for that topic and use these terms for everything else.
What you get
SaaS product build covers the work we plan and deliver under the retainer for the current term. We start with a discovery workshop, then we write a first-launch scope for your approval. That approved scope is what we build for the first launch, and anything outside it becomes a separate iteration with its own estimate that we only start after you ok it in writing.
Your proposal lists the deliverables for the first launch. As a reminder, they include: Discovery and scope cut; Clickable prototype and UI kit; Auth, roles, tenant separation; Stripe subscriptions and billing logic; Web app build (React/Next.js); API and backend services.
* Discovery and scope cut * Clickable prototype and UI kit * Auth, roles, tenant separation * Stripe subscriptions and billing logic * Web app build (React/Next.js) * API and backend services
Payment
We invoice setup work 50% to start and the other 50% when setup is complete. Ongoing retainer work is invoiced at the start of each month. Every invoice is payable within 7 days of its date.
If an invoice goes past due, we will tell you what is outstanding and what it blocks. Until the account is up to date, we can pause non-critical work, including new feature work and production releases, because shipping changes without a clear payment state is risky for both sides. If there is a genuine billing dispute, we will work with you to resolve it quickly, but undisputed amounts still need to be paid on time.
How you can use it
During the term you order, you can use the product, designs, and documentation we deliver for your internal business purposes for the users or seats covered by your order. This licence is for you only. You cannot resell, sublicense, or share access to the product or its deliverables outside your organisation unless we agree that in writing.
Code and repo access are handled differently: you own the repo and the code from day one. We work in your GitHub or GitLab, or we set it up in your organisation at kickoff, so you keep full admin access throughout. You can keep working on it with your team or another vendor at any time.
Support and response
We run the work with a named team: Mads Holm leads product decisions and scope control, Freja Mikkelsen owns UX/UI design, and Jonas Skovgaard leads implementation across frontend and backend. Day to day, you will have a single contact for priorities and scheduling, and we keep decisions written down so nothing depends on memory.
For issues, we use three severity levels you can apply when you report a problem: a “Launch blocker” (production down or a security issue), a “High impact” issue (core flow broken for many users), and a “Normal” issue (bugs, questions, small fixes). The response times and any service credits or remedies are exactly as stated in your order. If we miss a level, we will explain why, agree a recovery plan, and prioritise getting you stable before we pick up new work.
Your data
We process your data only to deliver SaaS product build and to support the product you ask us to run or change. You control what production data we can access. We will always use the least access needed, and we prefer working with staging or masked datasets when that is an option.
We take reasonable steps to keep your data secure in our tools and workflows (access controls, secure storage, and careful handling of credentials). If we become aware of a data breach affecting your data, we will tell you promptly, share what we know, and work with you on containment and next steps. When the engagement ends, we will return what we reasonably can and delete the rest from our systems, except where we must keep limited records for billing and audit.
Retainer renewal
SaaS product build is purchased as a retainer for the term shown in your order. Unless your order says otherwise, the retainer continues from term to term so your roadmap and maintenance do not stop unexpectedly.
If you do not want the retainer to renew, you need to tell us in writing by the notice period stated in your order. If the order does not state a notice period, we will agree one with you in writing before the first renewal decision point. When you give notice, we will help you plan a clean landing: what we can finish, what we should freeze, and what we should document so your team is not left guessing.
Limits and shared risks
We take responsibility for the work we control: how we design and build, how we document decisions, and how we help you ship safely. We do not take responsibility for things outside our control, like outages, policy changes, or unexpected behaviour in third-party services you choose and pay for (for example cloud hosting or Stripe).
We are not responsible for lost revenue, lost data, or knock-on costs from downtime. If something goes wrong, our job is to help you diagnose it, reproduce it in staging where possible, and ship a fix through the release process you approve. Security is a shared effort. We build auth, roles, and tenant separation as foundations and test boundary cases, but we cannot guarantee protection against every attack.
Ending the engagement
Either side can end the retainer by giving the written notice period stated in your order. If the order does not state a notice period, we will agree one with you in writing. We may also pause or end the engagement if work cannot continue for practical reasons, such as long-running lack of access, repeated missed approvals, or non-payment.
When the engagement ends, you pay for work completed up to the end date, plus any approved expenses. We will hand over what you need to keep moving: the repo (which stays in your organisation), access to build and deployment notes, environment and release documentation we have created, and a clear list of what is shipped, what is in progress, and what we recommend next. For 14 days after launch, we fix reproducible bugs caused by our code in the agreed production environment at no extra charge.
Signature
