A pre-launch operating rule

Private task management for stealth startups.

A stealth company can lose surprise through ordinary operational exhaust: a task title, a searchable backlog, a contractor invite, a due date, or a launch checklist copied into one vendor too many.

Minimize what exists. Encrypt what must exist. Share only what the next person needs. Keep source assets in the systems built to protect and govern them.

Last reviewed

Short answer.

SealTask can keep roadmap, fundraising, hiring, and launch coordination out of a readable task database. Keep code, credentials, deal documents, candidate records, and formal decisions in their authoritative systems. Task content is encrypted before sync, but membership, timing, status, relationships, and other operational metadata remain server-visible.

Stealth leaks through coordination.

Code repositories protect code. Virtual data rooms protect deal material. Password managers protect credentials. None of them replaces the daily queue that connects product, hiring, fundraising, and launch work.

Roadmap language reveals strategy before release.

Feature names, customer targets, integration plans, pricing experiments, and acquisition discussions can carry economic value even when no file is attached.

Every new collaborator expands the disclosure surface.

Contractors, advisors, agencies, and fractional operators often need a narrow workstream, not permanent access to the company’s complete operating plan.

AI convenience can require readable content.

Some task products process workspace text for summaries, suggestions, or search. SealTask has no server-side AI feature over workspace content and no server-held content keys.

Encrypted content is not invisible metadata.

SealTask servers store encrypted workspace content. They still process the metadata needed for accounts, memberships, synchronization, due dates, and task state.

Unreadable to the service

  • Readable task titles
  • Readable task bodies and notes
  • Readable recurring-task template content
  • Readable comment bodies
  • Readable checklist content
  • Readable project titles and descriptions
  • Attachment plaintext
  • Plaintext account passwords
  • Workspace content decryption keys

Server-visible workspace metadata

  • Account email addresses and workspace or project membership identities, roles, statuses, invitation states, and access timestamps
  • Database identifiers and relationships, including project owner, task and note creators, comment authors, delegation members, attachment uploaders, and per-member task-read cursors
  • Project timezone, section identifiers and policies, section timestamps, and task position or order
  • Task priority, completion and archive state and timing; note privacy and timestamps; per-member task-read timestamps; project timestamps and archive state; note, comment, and attention counts; and workspace write or collaboration entitlement flags
  • Recurrence schedule, timezone, active state, section, iteration, next-run, last-materialized, and task-materialization timestamps
  • Comment authorship relationships, counts, and timestamps; comment bodies remain encrypted
  • Delegation membership identifiers, roles, statuses, and timestamps; delegation notes remain encrypted
  • Attachment, project, and task relationships, including task-to-attachment link timestamps; storage identifiers; ciphertext byte size (which usually approximates original file size); upload capability expiry and protocol; status; and creation, update, or deletion timestamps; attachment content remains encrypted
  • Per-membership salts and membership proofs, plus the server-held project-scoped payload-binding key used to verify or compute matching HMACs; this binding key is not a workspace-content decryption key
  • Real-time event types; event, project, actor, membership, browser-instance, affected entity, section, and order identifiers; changed-field names; occurrence timestamps; and missed-event counts

This disclosure covers encrypted workspace content and its server-visible metadata. The workspace-content metadata inventory is complete for the enumerated current workspace persistence and SQL models, API-response models, and SSE event models. It is not a complete privacy-data inventory and excludes account authentication, billing, security and audit, abuse-prevention, and service telemetry domains; those domains are described non-exhaustively in the privacy policy. Metadata can itself be sensitive. Attachment ciphertext size usually reveals an approximation of the original file size.

A due date can reveal a launch window. Membership can reveal who is involved. Priority and open or closed state can reveal pressure. Use neutral task timing or keep especially sensitive milestones in an internal system whose metadata exposure you have assessed.

Inspect the security architecture

Worked example: Project Lantern enters private beta.

The task layer names the next action. The source systems retain the assets that create the company’s value.

SealTask

Lantern: confirm beta gate owner.

A neutral project reference, owner, and encrypted task body can coordinate readiness.

SealTask

Lantern: verify contractor access is removed after handoff.

For a fixed-term contractor, optionally choose an access-end date when inviting; leave it unset when access should continue until manual removal. Access review shows the contractor’s projects and last-active date; remove them from all projects you manage at handoff. Revoke repository, data-room, and other source-system access separately.

Specialist system

Source code, API secrets, and signing credentials.

Keep code in the repository and secrets in an approved secrets or credential manager.

Specialist system

Investor model, cap table, and signed financing documents.

Keep authoritative deal material in the finance system or controlled virtual data room.

Encryption is one reasonable protective measure. The stronger pattern is data minimization plus controlled access plus the correct system of record.

Put coordination in SealTask. Keep crown jewels elsewhere.

A task manager should not become a second repository for everything the company is trying to protect.

Work item SealTask System of record Why
Roadmap owner, dependency, and readiness task Yes — use neutral references when needed Product specification and decision system The task drives action; the product record preserves decisions and details.
Source code and security findings Reminder or issue reference only Code repository and security tracker Repositories own access, review, history, and remediation evidence.
Passwords, tokens, private keys, recovery codes No Secrets or password manager A task manager is not a secrets vault.
Fundraising and transaction documents Owner and follow-up only Virtual data room, finance, and legal systems Formal deal records need controlled distribution and authoritative versions.
Contractor launch workstream Yes — dedicated list with revocation Relevant product and asset systems Per-list access limits coordination scope; source access remains separately governed.

Four operating loops. One rule: narrow the disclosure.

The task list coordinates movement. Repositories, data rooms, ATSs, and decision logs keep the source material.

  1. 01 · Product

    Plan the pre-launch sequence.

    Track owners, dependencies, and readiness checks with project codenames or neutral references. Keep specifications, code, and security findings in the product systems that own them.

    ExampleLantern: confirm beta gate owner and rollback check.

  2. 02 · Fundraising

    Coordinate diligence without cloning the data room.

    Use tasks for owners and requested follow-ups. Keep cap-table data, investor materials, financial models, and signed documents in approved finance and deal systems.

    ExampleRound A: confirm owner for outstanding diligence request.

  3. 03 · Hiring

    Move a confidential search without copying candidate files.

    Track the operational next step with a role or candidate reference. The ATS remains the source for resumes, scorecards, compensation, and candidate communications.

    ExampleRole E-07: collect final interview availability.

  4. 04 · Launch

    Repeat readiness checks until release.

    Create recurring or sequenced tasks for legal, support, infrastructure, communications, and rollback readiness without placing credentials or unreleased assets in task attachments.

    ExampleLaunch minus seven: verify status-page draft owner.

A private task layer for the stage before the org chart settles.

Start alone, add one carefully scoped collaborator, and keep search local. The security model stays the same as the company grows.

Recurring tasks without recurring plaintext

Set repeating operational work once. The task content stays encrypted on the client before sync; due dates and recurrence timing remain operational metadata.

One shared list, not blanket access

Personal (€5.90/month) adds per-list sharing. Invite a collaborator only to the list they need. Removing a collaborator revokes their server-authorized access to the project. Using access review to remove them from every manageable project applies that same server-side revocation to each project. On the server that commits the change, active real-time streams are signaled after the commit; changes committed on another server and bulk or otherwise unsignaled changes are rechecked within the current authorization lease, at most 30 seconds. Bytes already delivered or buffered by the transport cannot be recalled. The current release does not automatically rotate any affected project key or re-encrypt projects for remaining members, and removal cannot erase content or key material obtained while the collaborator was authorized. If future sensitive work needs a fresh cryptographic boundary, create a new project and share it only with current members.

Private search on the device

Search runs after local decryption in the browser. SealTask does not need a readable server-side search index of workspace content.

A €0 solo starting point

Free includes one workspace, two projects, 100 MB of encrypted attachments, and 30-day audit history. No credit card is required.

Encryption is not a trade-secret designation.

SealTask does not determine whether information qualifies as a trade secret or whether your controls are legally reasonable. It is not a virtual data room, source repository, secrets manager, cap-table system, ATS, legal repository, or incident-response platform.

SealTask is not currently SOC 2 certified; accounts can add optional authenticator-app two-factor authentication (TOTP) with one-time backup codes. Teams should assess device security, identity controls, contracts, NDAs, offboarding, vendor risk, audit needs, and jurisdiction-specific requirements as a whole.

Removing a collaborator revokes their server-authorized access to the project. Using access review to remove them from every manageable project applies that same server-side revocation to each project. On the server that commits the change, active real-time streams are signaled after the commit; changes committed on another server and bulk or otherwise unsignaled changes are rechecked within the current authorization lease, at most 30 seconds. Bytes already delivered or buffered by the transport cannot be recalled. The current release does not automatically rotate any affected project key or re-encrypt projects for remaining members, and removal cannot erase content or key material obtained while the collaborator was authorized. If future sensitive work needs a fresh cryptographic boundary, create a new project and share it only with current members.

Questions this guide should answer.

Does using SealTask make information a trade secret?

No. Trade-secret status depends on applicable law and the facts, including whether information has value from secrecy and is subject to reasonable protective efforts. Software is only one part of those efforts.

Can SealTask see unreleased feature names?

SealTask cannot decrypt readable task, project, note, comment, checklist, recurring-template, or attachment content, and it does not receive plaintext passwords or workspace content keys. The service can still see operational metadata such as account and membership identities, relationships, task state and timing, recurrence schedules, attachment sizes and statuses, and real-time event identifiers. Metadata can itself be sensitive; the security architecture lists the complete current workspace inventory.

Can a contractor see only one project?

Paid plans support per-list sharing. Put the contractor’s operational work in a dedicated list, manage source-system access separately, and revoke both when the engagement ends.

Should API keys or recovery codes be attached to a task?

No. Keep secrets in an approved secrets manager or password manager and use a task only to reference the required action.

Does SealTask train AI on startup task data?

No. SealTask has no server-side AI feature processing workspace content, and the server does not hold the keys required to decrypt that content.

Sources and further reading.

  1. 01

    SealTask security architecture Open page Encryption, key handling, server visibility, and recovery tradeoffs

  2. 02

    SealTask pricing Open page Current Free, Personal, Team, and self-hosted terms

  3. 03

    Best encrypted task management Open page A source-backed comparison of encryption models and product tradeoffs

  4. 04

    USPTO — Trade secret policy Open source Defines the economic-value, secrecy, and reasonable-efforts elements of a trade secret

  5. 05

    FTC — Start with Security Open source Primary-source guidance to collect less, retain less, and avoid unnecessary uses of sensitive information

  6. 06

    NIST SP 800-171 Rev. 3 — Least Privilege Open source Limit authorized access to what is needed for assigned organizational tasks

Keep the plan readable only to the people building it.

Start with a private Free workspace. Add per-list sharing only when a real workstream needs it.