More of us can be builders now.I've spent decades building software and leading engineers, and AI changed who gets to do that.

AI opened that door, and honestly this platform wouldn't exist without it. But turning a vision into a product that actually holds up is still the hard part. This is what I built to make it easier, and it's free.

Why this exists

A year ago, there was a clear line between the people who imagine a product and the people who build it. I was on the building side, leading engineers who worked with product owners and an executive vision. That line has blurred. With AI, more of us can turn an idea into something real, and do it faster.

I've lived that. And I've learned that delivering a product that's genuinely quality, secure, scalable, observable, and cost effective is possible, but it isn't easy, and early on AI wasn't much help with that part on its own. So I built this.

If you're a builder with a vision for a SaaS product and you want an MVP you can demo, change, and put in front of people fast, this is for you. Marty Cagan's question in Inspired still holds: can you find five customers willing to pay for it before you build the whole thing? This is my attempt to make getting from vision to a solid product, with AI's help, a lot easier.

Two sides of one platform

The assistant your team uses runs on an AWS stack your developers own — the same platform, seen from two sides. For a small business, that's both at once; come in from whichever side fits you.

Document Assistant

Answer questions from your own documents

For business owners and teams. Upload your documents and get accurate, grounded answers in seconds — no code, no setup, no AI expertise required.

  • Upload your docs, ask in plain English
  • Answers grounded in your content — not made up
  • Says “I don’t have that yet” when it doesn’t know
  • Private and secure by default
Own it

Own the production-grade AWS starter

For developers. Get the full source — auth, IAM-authed database, CI/CD, observability, and a working AI (Bedrock RAG) module. It runs in your GitHub and your AWS account — you own it end to end, and we help you through setup.

  • Runs in your GitHub and your AWS — you own it, we help you set it up
  • AI-ready: grounded document Q&A on AWS Bedrock, included
  • Deploy in one command, free until you have real users
  • Regular AI + Cloud updates, pitfalls, and modules
  • A human operating model — ownership, forcing functions, a learning loop — so it actually holds up
  • Never pay twice for a mistake already solved here
The AI

The AI is built in and working

Grounded answers from your own documents, running on AWS Bedrock — included and working from the first deploy. No API keys, no model plumbing, no ML team. It answers from your content, and tells you plainly when the answer isn't there.

Grounded in your documents

Ask in plain English; answers come straight from your content — accurate and specific, never invented.

Honest when it doesn't know

When it doesn't know, it says “I don't have that yet.” No confident hallucinations, no guessing.

Your documents stay yours

Your documents stay in your account, isolated per user and IAM-authed — nothing shared, nothing trained on.

Powered by AWS Bedrock

Titan embeddings + Claude, wired and working out of the box — no API keys, no model plumbing, no ML team.

What's handled, so you can focus on your product

The parts most side projects skip until they bite you in production.

1

Auth and security, maintained

Sign-up, login, email verification, admin approval, brute-force lockout, bcrypt, JWT, and OWASP-style error handling. Dependency and secret scanning run on every push, and a security review sits on a schedule that a person actually owns.

2

Tested before it ships

Unit, contract, UI, and Playwright end-to-end tests, a staging gate, and smoke tests that run against real production before a deploy counts as done.

3

CI/CD

GitHub Actions test every push and gate every deploy. Nothing reaches production untested.

4

Observability you'll act on

CloudWatch alarms for errors, throttles, latency, and 5XX, plus a budget alarm. Each one has a runbook for what to do when it fires, and a check that your alert channel is actually live, so nothing fires into the void.

5

Cost caps

Per-user daily limits on the expensive operations, so one account or a runaway script can't run up your AWS bill. Tunable, and you can turn them off where you don't want them.

6

Your users' data rights

One-click data export and permanent account deletion, built in. An append-only audit trail of sensitive actions, so you can answer "what happened" during an incident.

7

Disaster recovery

Versioned S3 backups with a restore that's been round-trip tested, deploy rollback, and a DR runbook, because DSQL has no native point-in-time restore.

8

A legal starting point

Privacy Policy and Terms templates that match what the code actually does, with a review-before-launch checklist. Not legal advice, and not boilerplate that contradicts your own app.

9

The operating model behind it

The way of working that keeps all of this honest over time: ownership, forcing functions, and a growing library of mistakes already paid for. The part you can't copy from a repo.

What's included

Everything below is built and working — not a to-do list.

→

The AI module, wiredGrounded document Q&A on AWS Bedrock — Titan embeddings + Claude, an honesty gate, and per-user isolation. Included and working, not a stub to build later.

→

Agentic-readyA Bedrock tool-use loop and tool registry are wired in and tested — add your own tools. The path to approved, human-in-the-loop actions is documented, not hand-waved.

→

The stackVanilla JS SPA → API Gateway → Lambda (Node 24, Express) → Aurora DSQL (scales to zero) → SES — all IAM-authed, no long-lived DB password.

→

Auth done rightbcrypt, JWT, email verification, admin approval, brute-force lockout, enumeration prevention, password strength.

→

The full delivery pipelineSetup wizard, schema migrations, staging gate, smoke tests, frontend deploy with cache invalidation, a doctor health check.

→

CI/CD + observabilityGitHub Actions for test-on-push and gated deploys, plus one-command CloudWatch + budget alarms.

→

Disaster recoveryVersioned S3 data backups with a round-trip-tested restore, one-command backup/restore scripts, deploy rollback, and a DR runbook — because DSQL has no native point-in-time restore.

→

Data rights, quotas, and an audit trailOne-click data export and account deletion for your users, per-user daily cost caps so no one can run up your bill, and an append-only audit log of sensitive actions for when you need to know what happened.

→

Security, automated and ownedDependabot + scheduled secret/dependency scans catch the machine-checkable risks; a SECURITY.md runbook and a security-review.mjs forcing function put the human-judgment parts — alert triage, secret rotation, access audits, 2FA — on a tracked cadence. Automation flags; a human owns.

→

The ingredient guidesTesting, security, scalability, disaster recovery, observability and cost docs — so you understand the system, not just run it.

→

The "now what?" bridgeA guide that walks you from a working skeleton to your first real feature, in the order that never burns you.

From zero to deployed — even with no AWS account

Five steps. The heavy lifting is a single command; the rest is a clone and a deploy.

1

Create a free AWS account

No prior cloud experience needed — and if your team already has AWS chops, you'll move through this even faster. The free tier plus scale-to-zero DSQL keeps spend under $2/month until you have real users.

2

Install four tools

AWS CLI, GitHub CLI, Node 24, and psql — each a one-line install, all free.

3

Clone & provision

One command — node provision.mjs — creates the IAM role, DSQL database, secrets, Lambda, API Gateway, and S3 bucket. Idempotent and resumable if it stops.

4

Deploy

bash deploy.sh runs tests → staging → smoke tests → prod. bash deploy-frontend.sh ships the site and invalidates the cache.

5

Build your first feature

The FIRST_FEATURE guide walks you from a working skeleton to your first real feature — in the order that never burns you.

Prerequisites: an AWS account, plus AWS CLI, GitHub CLI, Node 24, and psql — nothing else, nothing paid.

Why this over a free boilerplate

A free boilerplate is a snapshot in time. This one is maintained, and it keeps improving as real projects hit real problems.

The real cost of building on AWS isn't the first deploy — it's the small, expensive mistakes between deploy and a stable product: the DSQL constraint that isn't standard Postgres, the API Gateway timeout at 29 seconds, the config call that silently wipes your env vars, the CloudFront cache that serves a stale frontend for hours. Each one is already a documented pitfall here, with the cost and the fix.

And it's a two-way street: when you hit a sharp edge or find a better pattern, you can send it back — improvements roll into the starter, so everyone building on it (you included, on your next project) benefits. You're not buying a static folder of files; you're building on something that gets better over time.

Better together

The human element this whole thing runs on

Generating code is the easy part now. What makes AI-built software actually trustworthy is a partnership: a human owns the outcome and the direction; the AI owns tireless craft, recall, and breadth. Neither produces this alone — and the discipline that joins them is the part you can't copy out of a repo.

Ownership

AI optimizes for “done” and has no stake in whether it actually works — only a human can own that. The kit is built ownership-first, with the checklists and gates as the expression of that ownership, never a substitute for it.

Forcing functions

The things that matter are gates, not notes: a staging smoke test that won't let a broken endpoint deploy, an end-of-session check that won't let project state rot. Quality doesn't depend on anyone remembering.

A learning loop that compounds

Every mistake becomes a dated, cost-tagged pitfall the next build can't repeat. The system gets smarter every session — you never pay twice for a lesson already learned.

Moments that made it better — real ones

Not marketing. Things that actually happened building this, where the partnership caught what neither side would have alone.

A human pushed back

The agent concluded a database migration was impossible and wrote it down as fact. A human said, “check the docs again.” It wasn't impossible — and that one exchange unblocked three-plus weeks of work that had been routed around by hand.

One real run beat six weeks of “done”

A provisioning script had looked finished for six weeks and passed every check. Insisting on a single real end-to-end run surfaced four bugs — each of which would have blocked every new user on their very first try.

Own it, then write it down

A feature shipped without a test. Instead of explaining it away, we owned it, fixed it, and captured the pitfall — so the gate now catches that class of mistake automatically. No blame, no essay, no next time.

AI accelerates execution. It doesn't transfer responsibility. The human element is what closes that gap — and it's built into how this is made, not left to chance. We're better together, and this platform depends on it.

A sample of what's inside

A few lessons already paid for

Five, out of a growing catalog, from a platform that keeps learning.

DSQL grants don't inherit

New tables don't pick up Lambda role permissions automatically — every CREATE TABLE needs an explicit GRANT, or the app 500s on first query.

Security filters block real users

A SQLi filter tuned on clean fixtures can reject a legitimate résumé upload the first time someone pastes an em dash or a semicolon.

Green tests can lie

A smoke test that silently skips every authenticated check deploys a broken endpoint — with a 100% passing suite.

RAG thresholds are shape-dependent

A grounding threshold tuned on prose can wrongly decline correct answers once real content is terse, like résumé bullets.

Model IDs get retired

An invoke that worked last month can throw "resource not found" — not an IAM bug, a deprecated model ID.

Built to kill the five churn points

Most builders abandon a SaaS attempt at one of five predictable cliffs.

The cliffThe fix
Setup too hardDependency-free setup wizard + SETUP guide + a doctor health check
First deploy failsdoctor validates the whole environment before you deploy; staging gate catches prod-path bugs
Cost shockSourced cost numbers + "free until real users" + budget-alarm setup
"Now what?"An end-to-end guided bridge to your first feature
DriftSchema contract, smoke tests, a pitfall catalog, and a live state file keep the project honest

What's intentionally not here yet

Honesty is part of the product. For a commercial SaaS you'll also need things this skeleton doesn't ship today — flagged plainly, and on the upgrade roadmap:

  • Payments and billing (Stripe). You can't charge customers yet.
  • Load and performance testing. The tests verify correctness, not behavior under heavy concurrency. The docs show where to add k6 or JMeter before a major launch.

Get access

Access is granted by invitation. Create an account below and verify your email, and you'll be approved before you can sign in.

Create account
Sign In
8+ chars Uppercase Lowercase Number Special char