Bolt.new + Stackbilder · Architecture review
Bolt.new App Hardening
for Production Teams
Browser-built full-stack apps ship fast with Bolt. Stackbilder adds architecture review, security pass, ADRs, and test plans before the code meets real users.
What Bolt.new is great at
Bolt runs in the browser and ships a full stack without local setup.
Bolt.new's defining advantage is the zero-install workflow. The entire development environment runs in the browser via StackBlitz's WebContainers technology — Node.js, npm, file system, and a live dev server, all in a browser tab. For founders who want to go from idea to deployed app without configuring a local environment, Bolt removes one of the most common friction points entirely.
The generated code follows strong Node.js/Express patterns. Bolt is genuinely good at wiring together React/Vite frontends with Express backends, handling basic CRUD routes, and producing SQLite-backed apps that work. The output isn't prototype-quality throwaway code — it's real JavaScript that real servers run. The production gap is the same as with all AI builders: the governance layer is absent. Security headers aren't documented. CORS is configured but the reasoning isn't. Input validation exists where the AI remembered to add it, which isn't the same as a validated strategy.
The production gap
What production requires that Bolt doesn't generate
These are the specific artifacts missing from Bolt's output that production Express.js apps require — before real users start hitting your routes.
Express middleware threat model
Bolt generates Express apps but doesn't document which middleware runs in what order, what CORS origins are allowed and why, or where the input validation boundary sits. T-001 through T-003 in a Bolt threat model almost always involve middleware gaps.
Database scaling ADR
SQLite works for solo and low-traffic apps. The decision to use SQLite instead of a hosted Postgres — and when to migrate — needs documentation. Bolt picks one; the architectural consequences of that choice need to be written down before you're mid-scale with a bad DB choice.
Async error handling test plan
Express doesn't catch async errors by default. Unhandled promise rejections in route handlers expose stack traces and crash worker processes. The test plan needs to cover error propagation, error response format, and what the 500 handler returns in production vs. development.
Input validation strategy
Bolt adds express-validator where it remembers to. A validation strategy document specifies what gets validated on every route, what sanitization runs, and what the reject-early policy is. This isn't per-route boilerplate — it's the policy that governs all routes.
CSRF protection documentation
Form-heavy Express apps need CSRF tokens on state-changing POST routes. This is especially relevant for Bolt apps that build admin panels or user settings flows. Documenting which routes need CSRF, which are excluded, and what the token verification middleware is — before you ship.
Rate limiting architecture
Express apps without rate limiting are open to credential stuffing on login routes and resource exhaustion on compute-heavy endpoints. The architecture document needs to specify where rate limiting lives, what the limits are per endpoint class, and what the 429 response format is.
What Stackbilder adds
Four governance artifacts specific to your Express + Node stack.
Express.js Threat Model
STRIDE analysis for Node.js/Express backends. Covers the five threats most common in Bolt apps: CORS misconfiguration, SQLite path traversal, missing CSRF protection, JWT secret rotation gaps, and verbose async error responses in production.
Express CORS allows credentials from all origins.
Severity: HIGH | Mitigation: explicit origin allowlist
## T-005 Information Disclosure
Async error in route handler returns full stack trace.
Severity: MEDIUM | Mitigation: sanitize 500 response body
Database Choice ADRs
The SQLite vs. hosted DB decision documented with traffic thresholds, migration path, and operational consequences. JWT secret strategy, session handling, and middleware ordering — all the non-obvious decisions Bolt made — recorded with reasoning.
Decision: SQLite (not hosted Postgres).
Context: Single-server deploy. < 10K rows projected.
Consequence: No connection pooling needed. WAL mode required
for concurrent reads. Migration: Turso at 50K rows.
Route + Error Test Plan
Test specifications for async Express route handlers, error propagation, input validation boundary cases, and rate limiting behavior. Covers the edge cases Bolt's generated code doesn't have tests for — the ones that surface in production.
test_async_error: rejected Promise in handler → 500 (no stack trace)
test_validation: invalid input → 422 with field errors
test_rate_limit: 11th req in window → 429 with Retry-After
Coverage target: 85% | Framework: supertest + vitest
Governed Scaffold
Project structure with constraint files documenting the middleware order, CORS policy, JWT rotation requirements, and rate limiting strategy. Reference point for future development — human or agent.
src/middleware/csrf.ts
src/middleware/rate-limit.ts
src/routes/api/
.ai/threat-model.md
.ai/adr-001-auth.md
.ai/adr-002-database.md
.ai/constraints.yaml
Example output
Threat model for a Bolt.new Express + SQLite SaaS
# Stackbilder Threat Model — Bolt.new / Express + SQLite
Pattern: node-express-sqlite | Generated: deterministic
## Spoofing
T-001: Express CORS allows cross-origin credentials from all origins.
Risk: Malicious site reads authenticated API responses.
Severity: HIGH
Mitigation: Set Access-Control-Allow-Origin to explicit allowlist.
## Tampering
T-002: SQLite file path derived from user input without sanitization.
Risk: Path traversal reads/writes arbitrary files on server.
Severity: CRITICAL
Mitigation: Validate and normalize all paths; use allowlist of DB names.
## Tampering (CSRF)
T-003: POST routes lack CSRF token verification.
Risk: Cross-site request triggers state changes on behalf of authed user.
Severity: HIGH
Mitigation: csurf middleware on all state-changing routes; SameSite=Strict cookie.
## Information Disclosure
T-004: JWT_SECRET stored in process.env without documented rotation policy.
Risk: Leaked secret signs arbitrary tokens permanently until rotated.
Severity: HIGH
Mitigation: Document rotation procedure. Invalidate sessions on rotation.
## Information Disclosure
T-005: Uncaught async Express errors return full stack traces.
Risk: Production error exposes file paths, dependency versions, schema details.
Severity: MEDIUM
Mitigation: Global error handler sanitizes response body in production.
How they work together
Bolt builds it in the browser. Stackbilder makes it production-safe.
Bolt.new solves the setup problem — no local Node, no npm install, no environment configuration blocking you from getting to code. Stackbilder solves the governance problem — no security analysis, no documented decisions, no test specifications to tell you when something breaks.
The recommended workflow: run Stackbilder before opening Bolt, use the ADRs and constraints to guide your Bolt session, and treat the threat model as a checklist to work through before you deploy. If you've already built in Bolt, the threat model becomes a code review protocol — each entry maps to something you need to verify or add to your Express codebase before it handles real traffic.
Bolt is not the risk. Shipping without the security and architecture layer is the risk.
Common questions
Can Stackbilder work with Express.js backends?
Yes. Express.js is one of the most common backends in Bolt-generated apps. Stackbilder's Express pattern covers CORS misconfiguration, missing security headers (helmet), input validation gaps, CSRF protection on state-changing routes, and JWT secret handling. The generated threat model maps directly to Express middleware architecture and documents what each middleware layer must enforce.
My Bolt app uses Firebase — does the threat model cover that?
Firebase-backed Bolt apps have a different threat profile than SQLite ones. Security Rules replace RLS, and client SDK initialization leaks config keys by design. Stackbilder's Firebase pattern covers Security Rules coverage gaps, Firestore access without auth, Storage rules misconfigurations, and Cloud Functions auth bypass. Describe your stack and the output adjusts to match.
Is Bolt.new suitable for production or just prototyping?
Bolt.new produces genuine full-stack code that many teams take to production. The StackBlitz environment means zero local setup, which lowers the barrier to iteration. The production question isn't about Bolt's output quality — it's about whether the security, test, and architecture documentation exists before real users land on it. That's what Stackbilder provides.
How do I use my Stackbilder threat model with my existing Bolt codebase?
Use the threat model as a code review checklist. Each threat entry (T-001 through T-00N) describes a specific risk and its mitigation. Walk through your Express routes against T-001 (CORS), your file operations against T-002 (path traversal), your POST routes against T-003 (CSRF). The test plan gives you the test cases to write. The ADRs document the decisions you've already made.
What governance documentation should every Bolt-built SaaS have before launch?
At minimum: a threat model identifying your injection, auth, and CORS risks; an ADR documenting your database choice and its scaling implications; a test plan covering auth flows, input validation boundaries, and error handling; and a deployment constraint document listing what configuration is required in production. Stackbilder generates all four in one scaffold run.
Related pages
Ready to harden your Bolt.new app?
Start free. Threat model, ADRs, and test plan with every scaffold. No credit card required.