Describe an idea, answer a few questions, and watch a real project get built — live.
An AI project builder with live previews, real-time collaboration and metered plans.
singularity.divyanshuagrahari.dev
Singularity is an AI-assisted project builder. You type a one-line idea; a short, AI-written interview turns it into a spec; an AI chat writes the project file by file while a checklist ticks off each step; and a live preview runs the result in its own Kubernetes pod as it's being built. Teammates collaborate with owner, editor and viewer roles, and usage is metered against plans billed through Stripe.
Live demo: https://singularity.divyanshuagrahari.dev — sign in with Google or email. Payments run in Stripe test mode; use card 4242 4242 4242 4242.
- Idea clarifier — 2–4 questions written by the model for your specific idea, compiled into a project brief before any code is generated.
- Streaming code generation — files are written live, with a build checklist and automatic recovery when a turn stops short.
- Live previews — every project runs in an isolated Kubernetes pod behind a signed, expiring preview link, shared correctly between collaborators and reclaimed when idle.
- Publishing — the owner publishes a production build of one saved revision at a link anyone can open, with no account; updates replace it atomically, and unpublishing or deleting the project takes it down. The code can be shared on a read-only page that anyone signed in can fork.
- Atomic file revisions — every AI turn lands as one all-or-nothing revision, and any earlier revision can be restored.
- Teaching mode — send a message in Teach mode and every step of that build can be opened for a lesson on what it changed: it starts from what you asked for, walks through only the changed lines (which the editor can jump to and mark), and hands over to the next step. The build opens with the big picture first - each file and its job, one action followed through them, the ideas it uses - then each step's lesson ends with a question to answer and leads to the next, and any line can be taken further in ExplainLLM: its syntax, why it is written that way, what removing it would do. Explanations are written for the level you choose (new to code, coded a little, developer). Lessons are written only when you open them, so the build is no slower, and kept with the conversation. Beyond one build, a Learn your project panel holds a tour of the whole project (each file and its job, and how a click travels through them) and a glossary: the words marked in a lesson open a plain definition with an example from your own code, and are kept. A lesson can also set a small Try changing this task: you make the change yourself in the editor, and the read-only model reads your saved file and tells you whether it is done.
- Code insight — ask about any selection or the whole project; answers are read-only by construction and saved as private notes.
- Collaboration — per-project roles, invitations, forking, pinning and starring, code search, and ZIP export.
- Plans and usage — Stripe subscriptions with enforced daily-token, project and preview limits, plus a usage dashboard broken down by day, feature and project.
- Clarify — a one-line idea becomes a spec through an adaptive interview.
- Generate — the spec starts an AI chat; the model reads the files it needs and streams edits in a tag-based protocol.
- Publish — when the turn completes, its file changes are published to object storage as one atomic revision.
- Preview — a warm Kubernetes pod is claimed, the project's files are synced in, and the Vite dev server runs there, routed to the browser through Redis and a small reverse proxy.
- Iterate — later turns edit the running project, and the preview reflects each completed turn.
A Spring Cloud Gateway routes each URL to one of three domain services, each with its own database. Services find each other through Eureka and call each other over a private, secret-authenticated internal API. Sign-in is Firebase-only; each service verifies the session itself. Generated code runs only inside isolated preview pods, never in the backend.
Read more: architecture overview · security model · design decisions
| Layer | Technologies |
|---|---|
| Backend | Java 25, Spring Boot 4.1, Spring Cloud (Gateway, Eureka, OpenFeign), Spring AI, PostgreSQL, Flyway |
| Frontend | React 18, TypeScript, Vite, Tailwind CSS, shadcn/ui, TanStack Query, CodeMirror |
| Integrations | Firebase Authentication, OpenRouter, Stripe, MinIO |
| Infrastructure | Kubernetes (kind, k3s), Kustomize, Redis, Docker, GitHub Actions, Cloudflare Tunnel |
Details and versions: tech stack.
Prerequisites: JDK 25, Node.js 20+, Docker, and a Firebase project and OpenRouter API key. Stripe keys are optional; a local kind cluster is needed only for live previews. See prerequisites.
git clone https://github.com/Divyanshu2805/singularity.git
cd singularity
# PostgreSQL and MinIO
docker compose -f services.docker-compose.yml up -d
cp .env.example .env # fill in your keys
# Backend: one terminal per service, in this order (mvnw.cmd on Windows)
./mvnw -pl common-lib install
MANAGEMENT_SERVER_PORT=9401 ./mvnw -pl discovery-service spring-boot:run
MANAGEMENT_SERVER_PORT=9402 ./mvnw -pl account-service spring-boot:run
MANAGEMENT_SERVER_PORT=9403 ./mvnw -pl workspace-service spring-boot:run
MANAGEMENT_SERVER_PORT=9404 ./mvnw -pl intelligence-service spring-boot:run
MANAGEMENT_SERVER_PORT=9405 ./mvnw -pl gateway-service spring-boot:run
# Frontend
cd frontend && npm install
cp .env.example .env.local # Firebase web config
npm run devOpen http://localhost:5173. The full guide, including live previews and troubleshooting, is in local development.
./mvnw verify # backend: 1,308 tests across all modules, and each module's coverage floor
cd frontend && npm test # frontend: 845 tests
cd proxy && node --test # preview proxy
(cd e2e && npm test) # one person's whole path in a real browser, against the stack e2e/stack.sh startsThe backend suite is plain JUnit and needs no database or cluster, except one Testcontainers integration test (which needs Docker). A real preview on a kind cluster and the browser journey each run in CI on every push. What has been measured - waits, cost per build, load, Lighthouse, coverage - is in the product's numbers. See testing.
common-lib/ shared error model, session authentication, internal-API plumbing
discovery-service/ Eureka service registry
gateway-service/ Spring Cloud Gateway — the browser's single origin (:8000)
account-service/ users, plans, subscriptions, Stripe, sessions (:8081)
workspace-service/ projects, members, files, revisions, live previews (:8082)
intelligence-service/ AI generation, code insight, idea clarifier, usage (:8083)
frontend/ React single-page app
proxy/ Node reverse proxy for preview hostnames
k8s/ local preview-pipeline manifests (kind)
deploy/ production Kubernetes manifests (Kustomize) and deploy scripts
docker/ shared service Dockerfile and the preview-runner image
infra/postgres-init/ creates the service databases on a fresh volume
docs/ documentation
The live demo runs on a single free-tier Oracle Cloud Arm VM as single-node k3s, with no open inbound ports: visitors arrive through a Cloudflare tunnel, and deploys arrive over Tailscale. GitHub Actions tests every change, builds eight arm64 images, deploys them, smoke-tests the site and rolls back automatically on failure. A nightly job backs up the databases and object storage to Cloudflare R2.
See deployment and operations.
| Section | Contents |
|---|---|
| Local development | Setup, configuration, live previews, troubleshooting |
| Architecture | Services, request flows, security model, decision records |
| API reference | Every endpoint, streaming formats, errors |
| Data model | Databases, entities, schema conventions |
| Engineering practices | Conventions, testing, guardrails, known pitfalls |
| Known gaps | Trade-offs and what isn't built yet |
| Deployment · Operations | Running it in production |
The full index is at docs/.
CONTRIBUTING.md describes how to work on the codebase: the workflow, conventions and checks every change goes through. To report a security issue, follow SECURITY.md instead of opening a public issue.
Singularity began as a single Spring Boot application and was split into the current services in stages; the original monolith was then removed (ADR 0001). Both are preserved in git history:
| To see | Command |
|---|---|
| The monolith, just before the split began | git switch --detach a0c9214 |
| The migration record — what moved where, the cutover, lessons learned | git show 3257326:docs/migration/ |