Aha! Builder governance FAQs

Yes. You own all code and intellectual property created in Aha! Builder. Aha! has no claim on anything you build. You can download the full codebase at any time and use it however you choose.

Yes. Developers get full access to the generated code, including the backend and the Postgres database. The generated code is a standalone TypeScript application. It is separate from your existing product codebase, not merged into it.

Yes. Navigate to Implement → Code and click Download ZIP to get the complete codebase. You can run it independently of Aha! at any time.

Governance administrators on the Aha! Builder Team and Scale plans can use the governance page to manage application policies from one place. Once you have governance administrator permissions, you can navigate to the Governance tab in the top navigation bar to:

• View all applications and their deployment status, authentication methods, security review results, and more on the Applications tab.

• Set default rules that control which authentication methods, deployment permissions, internet access, email delivery, and AI capabilities are available across all applications.

• Create rules templates with different governance configurations for different types of applications — for example, stricter controls for production applications and more permissive rules for prototypes.

Yes. Navigate to Operate → Documents → Security to run and review security assessments for your application. The Code security tab includes four review types:

• Review for secure by design principles: Checks that security is built into the application architecture from the start.

• OWASP top 10 review: Assesses the application against the ten most critical web application security risks.

• Static code analysis: Automated review of source code for potential security flaws, coding errors, and unsafe patterns

• Dependency vulnerability scan: Checks application dependencies for known security weaknesses.

Each review produces a score, a pass or fail Status, and a downloadable Report. Click Repeat review to rerun any review after making changes.

The Privacy tab includes four additional review types:

• Personally identifiable information (PII) review — identifies and documents all personal data collected, processed, and stored by the application

• GDPR review — assesses compliance with General Data Protection Regulation requirements

• CCPA review — assesses compliance with California Consumer Privacy Act requirements

• Cookie usage review — analyzes all cookies used by the application, their purposes, and regulatory compliance

These reviews help you demonstrate compliance with your organization's internal governance standards. You can download reports and share them with your security and compliance teams.

Yes. Aha! Builder maintains complete separation between the Preview and Production environments. Each environment has its own database, authentication configuration, user list, and integrations. Changes in one environment do not affect the other.

No. End users do not need an Aha! account. Aha! Builder applications use their own authentication, separate from Aha! account credentials.

Aha! Builder supports five identity providers for end-user authentication:

• Aha!

• Password

• Google

• GitHub

• Microsoft

Yes. Governance administrators can disable specific authentication methods at the account level using default rules or rules templates on the governance page. When an authentication method is disabled in a governance rule, it becomes unavailable for all applications covered by that rule — even if an application owner has configured it.

Aha! Builder runs on the same AWS infrastructure as all other Aha! products. Applications are hosted by Aha! with underlying data center services provided by Amazon Web Services in the US East (Northern Virginia) region.

Aha! maintains ISO 27001 certification. The underlying AWS infrastructure holds SOC 1, 2, and 3 certifications.

• In transit: TLS 1.2 and 1.3 with strong ciphers. Production certificates are generated by Let's Encrypt and automatically renewed.

• At rest: Code, databases, and file storage are automatically encrypted using AES-256 encryption.

A network firewall limits access to only the running application.

Production applications are constantly monitored and automatically restarted if issues are detected. Deployments use a blue-green strategy: Aha! starts and monitors the new version before switching traffic from the previous version. If any issues are detected with the new version, traffic continues to be served by the previous version while the new version is fixed and redeployed.

• Code: Backed up automatically once an hour. Most code changes are also stored in a git revision control system, which enables fine-grained rollback.

• Database: Backed up hourly and retained for 30 days.

• High availability: The database runs in high-availability mode with a hot replica in a separate data center.

Each application gets its own Postgres database and its own data model. You have full access to the database through Operate → Configuration → Database. Preview and Production databases are completely separate. Data does not carry over between environments.

Yes. Navigate to Operate → Configuration → Integrations to configure external connections such as Salesforce, Hubspot, Slack, and Aha! Roadmaps. Secrets let you store API keys, tokens, and other credentials that your application uses to connect to external systems. Preview and Production secrets are managed separately.

Yes. You can integrate an Aha! Builder application with your Aha! account. Soon, you will also be able to send features from Aha! Roadmaps directly to your Builder application and install a feedback widget to collect end-user input that flows into your ideas portal.