Current service architecture
Goalward is a Next.js application hosted on Vercel. Supabase provides account authentication and the Postgres database used for planning sessions, goals, inputs, themes, priorities, roadmap assignments, saved roadmaps, and first-party product events.
The product currently uses account-based access. It does not offer shared workspaces, invitations, public roadmap URLs, single sign-on, enterprise administration, billing, or AI-generated recommendations.
Authentication and access control
Supabase Auth manages email and password authentication and browser sessions. Goalward does not store plaintext passwords in its application database.
Database row-level security policies are used to restrict product records to the authenticated account that owns the planning session. Server-side actions also perform authentication and input checks close to the data operation. Authorization remains a database responsibility rather than relying only on hidden interface controls.
- Private application routes require an authenticated session.
- Planning records are linked to an owning account through their planning session.
- Analytics insert access is restricted to authenticated accounts, with additional session-reference hardening staged for separate owner-approved rollout.
Data and analytics boundaries
Goalward stores the planning content needed to save and reopen your work. The current Share step copies or downloads a roadmap brief; it does not publish the roadmap on a public URL.
First-party analytics events are intended to record workflow events without goal, input, theme, roadmap, email, credential, or token content. Vercel Web Analytics URLs are filtered to remove planning-session identifiers and known sensitive authentication parameters.
Google Analytics is optional and is loaded only after consent. The declared events use narrow parameters such as the email authentication method or share method, not roadmap text.
Operational practices
Production changes are expected to pass lint, tests, and a build before release. Database migrations are versioned, reviewed separately from application deployment, checked with a dry run and database lint, and require owner approval before remote application.
The release runbook requires a preview check, public and authenticated smoke tests, migration-history verification, health checks, and a documented rollback decision. Secrets must remain in provider environment settings and must not be committed or exposed through public environment-variable names.
Launch-stage limitations
This page is a description of current practices, not a security certification or a promise that incidents cannot occur. Goalward does not currently claim SOC 2, ISO 27001, HIPAA, PCI DSS, or any independent product-security certification.
Formal incident-response contacts, user-facing account deletion, a vulnerability disclosure channel, documented recovery objectives, external penetration-test results, and enterprise security controls are not currently published. Those gaps should be resolved according to customer risk before the product handles more sensitive or regulated use cases.
Reporting a security or privacy concern
A dedicated security and privacy contact address is still to be confirmed before broader public launch. Until that contact is published, do not send vulnerability details or sensitive account information through an unverified channel.
When a verified reporting channel is added, reports should include the affected URL or feature, reproduction steps, impact, and a safe way to follow up. Do not access another user’s data, disrupt the service, or retain data while investigating a concern.