SomethingGet the first build

Draft, under legal review. This text is not in force and may change before launch.

Data Processing Agreement for Something

Version 0.1 · Last updated 30 October 2026 ·

Draft. For review by BAARS DESIGN and its lawyer before use. Not legal advice. This DPA is written for business customers (Team and Enterprise). Annex 2 is deliberately honest about what exists today and what is planned; a lawyer should check it against the final build before the first signature. Text in [square brackets] is a placeholder.

This Data Processing Agreement (“DPA”) is part of the agreement between the customer named in the order form or account (“Customer”) and BAARS DESIGN, organisation number 938 054 037, Norway, with the registered address shown on the Company information page (“BAARS DESIGN”), for the use of Something (the “Service”).

It applies where BAARS DESIGN processes personal data on behalf of the Customer, as the GDPR Article 28 requires. For Customers in Norway the GDPR applies through personopplysningsloven (LOV-2018-06-15-38) § 1.

1. What this DPA covers, and what it does not

What BAARS DESIGN processes for you. When your organisation uses Something, we hold the personal data of your members that is needed to run the organisation: their names, email addresses, roles, seats, invitations, sign-in records, device records, usage counts, and an audit log of administrative actions. For that data you are the controller and we are your processor. Annex 1 lists it.

What never reaches us. Your repositories, code, designs, prompts, AI responses, screenshots and pull requests are processed on your members’ Macs, on your own code host (GitHub or another), and by the AI provider your members connect under your own agreement with that provider. None of it passes through BAARS DESIGN’s systems. This DPA does not cover that data because we do not process it. The only exception is the planned hosted “before/after” page linked from a pull request, which is covered in Annex 1 if you turn it on.

Where we are the controller. For billing records, our own tax and accounting duties, and our direct relationship with the person who holds the account, BAARS DESIGN is a controller under its Privacy Policy. This DPA does not cover that.

2. Definitions

“GDPR” means Regulation (EU) 2016/679 as it applies in the EEA, including in Norway through personopplysningsloven. “Personal data”, “processing”, “controller”, “processor”, “data subject” and “supervisory authority” have the meanings in the GDPR. “Subprocessor” means another processor engaged by BAARS DESIGN. “Customer Personal Data” means the personal data described in Annex 1.

3. Roles and instructions

3.1 The Customer is the controller and BAARS DESIGN is the processor of Customer Personal Data.

3.2 BAARS DESIGN processes Customer Personal Data only on the Customer’s documented instructions. The Customer’s instructions are: this DPA, the Terms of Service, the Customer’s configuration of the Service (members, roles, seats, settings), and further written instructions agreed between the parties. If BAARS DESIGN believes an instruction breaks the law, it will tell the Customer.

3.3 BAARS DESIGN may process Customer Personal Data where EU or Norwegian law requires it. In that case it will tell the Customer before processing, unless the law forbids it.

4. Confidentiality

BAARS DESIGN makes sure that every person it authorises to process Customer Personal Data is bound by confidentiality. At the date of this draft BAARS DESIGN has one person with access: its owner. If staff or contractors are added, they will be bound in writing before access is given.

5. Security

5.1 BAARS DESIGN implements the technical and organisational measures in Annex 2, taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing, as Article 32 requires.

5.2 BAARS DESIGN may update Annex 2, but not in a way that lowers the overall level of protection during the term.

6. Subprocessors

6.1 The Customer gives general authorisation for BAARS DESIGN to engage the subprocessors listed in Annex 3 (the Subprocessor list).

6.2 BAARS DESIGN gives the Customer at least 30 days’ notice by email before adding or replacing a subprocessor. The Customer may object in writing within that period on reasonable, data-protection related grounds. If the parties cannot resolve the objection, the Customer may terminate the affected part of the Service and receive a pro-rata refund of prepaid fees.

6.3 BAARS DESIGN puts each subprocessor under a written contract with data protection obligations at least as protective as this DPA, and stays fully liable to the Customer for the subprocessor’s performance.

7. International transfers

7.1 Customer Personal Data is stored in the EEA. See Annex 1 for locations.

7.2 Where a subprocessor processes Customer Personal Data outside the EEA, BAARS DESIGN relies on an adequacy decision (including the EU-U.S. Data Privacy Framework for a certified US recipient) or on the Standard Contractual Clauses under Commission Decision (EU) 2021/914, as recorded in Annex 3. Copies of the relevant clauses are available on request.

7.3 BAARS DESIGN does not transfer Customer Personal Data outside the EEA itself except through the subprocessors in Annex 3.

8. Helping the Customer

8.1 Data subject requests. If a data subject contacts BAARS DESIGN about Customer Personal Data, BAARS DESIGN will refer them to the Customer and, on the Customer’s instruction, help answer the request. Organisation admins can view, correct and remove members themselves in the Service.

8.2 Security incidents. BAARS DESIGN will tell the Customer without undue delay, and in any case within 48 hours of becoming aware, of a personal data breach affecting Customer Personal Data, with the information Article 33(3) requires as far as it is known, and will update as more is known.

8.3 Impact assessments. BAARS DESIGN will give the Customer the information it reasonably needs for a data protection impact assessment or consultation with a supervisory authority, to the extent it relates to the Service.

9. Audits and information

9.1 On request, no more than once a year unless a supervisory authority requires it or a breach has occurred, BAARS DESIGN will give the Customer the information needed to show compliance with this DPA: this DPA, Annex 2 as currently implemented, the subprocessor list, and answers to a reasonable security questionnaire.

9.2 If that is not enough, the Customer or an independent auditor bound by confidentiality may audit BAARS DESIGN’s processing on 30 days’ notice, during business hours, without disrupting operations. The Customer bears the cost of the audit unless it reveals a material breach.

9.3 BAARS DESIGN holds no SOC 2 or ISO 27001 certification at the date of this draft, and this DPA does not promise one.

10. Deletion and return

10.1 When the Customer’s organisation is deleted or the agreement ends, BAARS DESIGN deletes Customer Personal Data within [30] days, except what EU or Norwegian law requires it to keep (such as invoicing records under bokføringsloven § 13, kept for five years after the end of the accounting year) and except pseudonymised audit log entries.

10.2 Before deletion, the Customer may export its organisation’s data (members, roles, audit log) in JSON from the admin console or by request.

10.3 Data on members’ Macs is under the Customer’s control and is not touched by BAARS DESIGN.

11. Liability

Liability under this DPA follows the limitation of liability in the Terms of Service or the Enterprise agreement, except where the GDPR provides otherwise. Each party is liable for the administrative fines imposed on it.

12. Term, precedence and law

12.1 This DPA runs for as long as BAARS DESIGN processes Customer Personal Data.

12.2 If this DPA conflicts with the Terms of Service, this DPA wins for data protection matters. If a signed Enterprise agreement contains its own data processing terms, those win.

12.3 This DPA is governed by Norwegian law, with the venue in the Terms of Service.

12.4 For Team customers, this DPA is accepted by accepting the Terms of Service when creating an organisation. Enterprise customers sign it with the order form.

Annex 1: Details of processing

Subject matter. Running a Something organisation (team account) for the Customer.

Duration. The life of the organisation, plus the deletion period in section 10.

Nature and purpose. Authenticating members; managing membership, roles and seats; issuing entitlement tokens that unlock plan features in the app; keeping an audit log of administrative actions; counting usage per seat for billing and fair use; sending transactional email (invites, sign-in codes, notices).

Categories of data subjects. The Customer’s employees, contractors and other people the Customer invites as members or admins. Billing contacts.

Categories of personal data.

Data Source Where stored
Name, email address, sign-in provider and provider user id The member, via Google, Apple or email sign-in Supabase Auth (AWS Stockholm, planned) and the backend database
Sign-in times and IP addresses The sign-in service Supabase Auth logs (planned); retention [90] days
Organisation membership: role, seat, who invited, when accepted Admin actions in the Service Backend database
Invitation emails and expiry Admin actions Backend database; invites expire after [7] days
Device records: Mac name, platform, app version, first and last seen The app, on token refresh Backend database; [12] months after last seen
Usage counts: pull requests sent per seat per month; project counts The app, on token refresh Backend database; counts only, never content
Audit log: actor, action, subject, time Admin actions Backend database; [2 years]; actor pseudonymised on account deletion
Hosted before/after pages (optional, planned, off by default) Screenshots of the member’s design change, uploaded only when the member turns the feature on for a pull request [Storage provider to be decided]; private, expiring links

Special categories. None. The Customer must not use the Service to process special categories of data (Article 9) or criminal-conviction data.

Location. EEA: Sweden (Supabase/AWS Stockholm, planned) and [Norway or an EU region of the backend host, decision pending]. Support email on BAARS DESIGN’s mail server hosted by Oracle Cloud ([Amsterdam region per admin record]). Transfers to the US and Singapore only through the subprocessors in Annex 3.

Decision: the retention numbers in brackets. They are proposals that match the Privacy Policy and should be set once and used in both documents.

Annex 2: Technical and organisational measures

This annex says what exists and what is planned. “Exists” means in the current code or in operation on 2026-10-30. “Planned” means a design commitment in docs/AUTH-AND-BILLING.md and docs/ACCOUNTS.md that is not built yet. Before the first signature, every “Planned” line must be either built or removed.

Data minimisation (exists)

  • The Service is designed so that the Customer’s code, designs, prompts and AI output never reach BAARS DESIGN. They are processed on the member’s Mac, the Customer’s code host and the Customer’s AI provider.
  • The backend holds account, membership, plan and count data only.
  • The app contains no analytics or telemetry code (verified by source search on 2026-10-30).

Credentials on the Mac (exists)

  • Session tokens, GitHub tokens and AI keys are stored in the macOS keychain under the service name “Something”, never in files. Values are passed to the keychain over stdin, never on a command line.
  • The access token is kept in memory only. The app’s web page never receives a token.
  • Plugins cannot address keychain entries owned by the account or GitHub integration.
  • Sign-in uses PKCE in the system browser with a loopback redirect (RFC 8252). The app holds no client secret.

Transport (exists)

  • All connections to BAARS DESIGN, Supabase, Stripe, GitHub and AI providers use TLS.

Software integrity (exists)

  • Releases are signed with an Apple Developer ID certificate, hardened runtime, and notarized by Apple. Updates are verified against a SHA-512 hash and the signature; a mismatched update is refused. Updates come from a public repository that holds only installers.

Backend security (planned)

  • Verification of sign-in tokens against the identity provider’s published keys, checking audience, expiry and that the user exists and is not deleted.
  • Stripe webhooks verified by signature, with replay protection by event id.
  • Entitlement tokens signed with Ed25519; the private key in the backend’s secret store, rotated yearly; the app ships only the public key.
  • Rate limits per user. CORS closed. Logs that never contain tokens and that hash email addresses.
  • Encrypted database storage and daily encrypted backups with [30]-day retention, in the EEA.
  • Account deletion endpoint that erases the user at the identity provider and pseudonymises the audit log.

Access control at BAARS DESIGN (exists, small scale)

  • One person has administrative access to production systems: the owner. Access to the mail server, Stripe, GitHub, Supabase and hosting accounts uses unique accounts with two-factor authentication [confirm for each account].
  • No credentials are stored in the source repository; secrets live in the keychain, in a password manager, or in the host’s secret store.

Organisational (exists, small scale)

  • Breach notification procedure: section 8.2 of this DPA and Articles 33 and 34 of the GDPR.
  • Subprocessor review before engagement: DPA, location and transfer mechanism recorded in Annex 3.
  • No SOC 2 or ISO 27001 certification. A completed security questionnaire is available on request.

Lawyer and owner: confirm two-factor authentication on every provider account, and decide the backup retention number, before this annex is used.

Annex 3: Subprocessors

The current list, with purpose, data, location and transfer mechanism for each, is the Subprocessor list. It forms part of this DPA. Changes follow section 6.

Sources used for this draft (read 2026-10-30)