Security practices at Downshift
For founders evaluating a $30K+ engineering engagement, security is not optional. This page documents how Downshift actually handles code, credentials, data, and AI tools during a build. No marketing fluff. What we do, what we don't do, and what we don't claim.
Source code and IP
You own the code from day one. The GitHub repository is created under your organization or transferred to you at project launch. There are no clauses retaining IP, no license-back arrangements, no "we own the framework" asterisks.
During the build, Downshift engineers have write access to the repository. At handoff, access is revoked. You control who has access from that point forward.
All code is committed to git with full history. Every change is traceable to a commit, a branch, and a reason. No black boxes.
Access management
During a build, access is limited to the Downshift engineering team working on your project. No shared credentials across projects. No intern access. No third-party contractors unless explicitly disclosed and approved.
At project completion, all access is revoked: GitHub repository, cloud provider accounts, database credentials, third-party service accounts. You receive a handoff checklist confirming every access point has been transferred or removed.
If you use Railway, Vercel, or AWS, Downshift works within your accounts rather than maintaining separate infrastructure you can't see.
Secrets management
No secrets in code. Ever. API keys, database credentials, and tokens are stored in environment variables on the deployment platform (Railway, Vercel, etc.) and never committed to the repository.
.env files are gitignored by default. Encrypted secret management is used for local development. Production secrets are set through the hosting platform's dashboard, not through files that could leak.
At handoff, you rotate all credentials. Downshift provides a checklist of every secret that needs rotation so nothing is missed.
Deployment security
Every project ships with a CI/CD pipeline. Code pushes to main trigger automated builds. Promotion to staging and production goes through defined branches, not manual uploads.
Branch protection is enabled: no direct pushes to production branches. Pull requests are required for production deployments. Automated type checking and linting run on every commit.
Dependency audits run as part of the build process. Known vulnerabilities in packages are flagged before they reach production. Outdated dependencies are tracked and updated on a regular cadence.
AI tool usage
Downshift uses AI tools daily (Claude Code, Cursor, and others) for code generation, testing, and deployment automation. This is how we ship at 3-5x velocity. Here is what that means for your data:
Code context goes to AI providers. When using Claude Code or Cursor, code from the repository is sent to Anthropic or OpenAI for completion and analysis. These providers have data retention policies (typically: not used for training, deleted after processing). If your engagement requires zero-AI-exposure, disclose this upfront so we can scope accordingly.
Customer data does not go to AI during development. We use test data and fixtures during development, not your production user data. AI tools see code structure, not customer PII.
Production AI features are different. If the product we build includes AI features (e.g., a chatbot that uses OpenAI), the data handling for those features is documented in the product's own privacy policy and follows provider-specific terms. This is scoped during the PRD phase.
Customer data handling
For products that store user data (most SaaS products do), Downshift builds with these defaults:
- Encryption in transit: HTTPS everywhere. No exceptions. SSL certificates managed by the hosting platform.
- Encryption at rest: Database encryption enabled by default on Railway/AWS. Sensitive fields (passwords) hashed with bcrypt or argon2.
- GDPR/CCPA defaults: Consent banners, data export endpoints, account deletion flows built into the product from launch.
- Retention policies: Founder-controlled. You decide how long data lives. We build the infrastructure to enforce it.
- Backups: Automated database backups with point-in-time recovery. Configured as part of the production setup.
Incident response
If something breaks in production during the engagement or the 30-day post-launch window:
- Detection: Error monitoring (Sentry) and analytics (PostHog) are set up from day one. Alerts fire on error spikes and availability drops.
- Communication: Founder is notified immediately via the agreed channel (Slack, email, or text). No waiting for a scheduled standup.
- Fix: Root cause identified and fixed. Deploy goes out with the fix. No "we'll look at it next sprint."
- Postmortem: Written summary of what happened, why, and what changed to prevent recurrence. Shared with the founder within 24 hours.
What we don't claim
Honesty about scope matters more than marketing claims. Here is what Downshift does not currently have or claim:
- No SOC 2 certification. Downshift is a small engineering team, not a data center. SOC 2 applies to how your product handles data, and we build that into the product. But the agency itself is not SOC 2 audited.
- No HIPAA BAA. If your product handles PHI, we can build HIPAA-aligned architecture, but we are not a HIPAA-covered entity and don't sign BAAs as an agency.
- No FedRAMP authorization. We don't serve government contracts requiring FedRAMP.
- No bug bounty program. We don't run a formal bug bounty. Security issues are handled through direct communication.
- No pen test reports. We don't commission third-party penetration tests on the agency. We can scope pen testing for your product as part of the engagement if needed.
If your engagement requires any of the above, tell us upfront. We'll either scope it into the project or tell you honestly that we're not the right fit.
Questions about security?
Security details are discussed during the pre-engagement call. If you have specific compliance requirements, bring them early so we can scope correctly.
Also see: Privacy Policy · Terms of Service · Our Process