Software Development Policy

Busymate DevTools is developed and operated as a single monorepo covering the iOS app, the Android app, the web dashboard, the REST and realtime APIs, the MCP server, the CLI tools, and the Supabase-hosted backend. Changes to any of these move through the same process described below before they reach a live, customer-facing environment.

Every change is expected to add or update an automated test in the same change that introduces the behavior it covers — internally we call this “every change ships its own test.” Tests are organized into tiers, from checks that run in seconds with no external dependencies up to checks that exercise a real, isolated instance of the backend.

A guiding rule of our test and release tooling is that a check must fail closed: if a check cannot determine whether something is correct — because a dependency is unreachable, a file is missing, or an input can't be parsed — it is required to report that it could not verify the condition, never to report success by default. “Couldn't check” is treated as a distinct outcome from “checked and passed,” and is never silently treated as a pass.

The main line of our source code is protected at the hosting-provider level, not only by local convention. A change cannot be merged into it unless an automated status check has run against that exact set of changes and reported success — that restriction applies to every contributor, including administrators of the repository, so no single person can push a change around the check. History-rewriting force-pushes and deletion of the main line are disabled outright.

Day to day, changes are additionally checked by automated linting, type-checking, and the test tiers described above before they are merged; changes that touch security-sensitive areas — authentication, authorization, billing, or direct data access — are checked by review tooling built specifically for that class of change.

Operational credentials used to run the service are not stored as plain values in source control. Long-lived application secrets are held in an encrypted, write-only store: once a value is set, there is no interface — for an administrator, or for any AI assistant with access to the system — to read that value back. A secret can only be used by the system it was configured for, or replaced with a new one. Changes are automatically scanned before they are accepted for credentials that were accidentally included in the change itself.

Access to a customer's data inside the dashboard is enforced by role-based permissions applied at the database layer, not only inside the application's user interface — so the same limits hold whether the data is reached through the dashboard, the API, a realtime connection, or an AI assistant acting on a signed-in user's behalf. Actions taken against the system, including direct database access by the team, are recorded in an append-only audit trail that is not itself editable after the fact.

Busymate DevTools is built on open-source software. The specific third-party packages in use across the website, the iOS app, and the Android app — their versions and their declared licenses — are tracked and published on our Acknowledgements page, generated directly from the project's real dependency manifests rather than compiled by hand, so it stays accurate as dependencies change.

The product is made up of several independently-versioned components — the iOS app, the Android app, the dashboard, the API surfaces, and others — each deployed and version-tracked on its own schedule rather than as a single combined release. A running component reports its own current version, so what is actually live in production can be checked directly rather than inferred from a changelog.

For a suspected compromise of an operational credential or a piece of infrastructure, our practice is to rotate the affected credential or access first and investigate the cause second, to limit how long a compromised credential remains usable — then to review recent activity for signs the exposure was actually used.

This page describes engineering practice as it runs today. The following are deliberately not stated above because they are decisions the business has not yet made, not facts about our current process — we would rather name them plainly than guess:

• whether a formal, mandatory second-person review is required on every change (today, review relies on the automated gates described in §3, not a guaranteed human sign-off on each change);
• whether Busymate pursues or holds a third-party security or compliance certification (e.g. SOC 2, ISO 27001);
• whether there is a dedicated security-disclosure contact separate from general support, and the terms of a vulnerability-disclosure or bug-bounty program, if any;
• any formal uptime or service-level commitment for paid plans.

We may update this policy as our engineering practice evolves. Material changes will be reflected by updating the date at the top of this page.

Questions about this policy: support@busymate.net.