Everything we can prove.And everything we cannot.
ViberSpace turns a plain-language description into a conventional Rails application in a real GitHub repository, deployed to environments your team promotes by hand. Below is the review an enterprise runs before it allows any of that — 21 questions, answered in full. 11 of the answers are no.
Access is by invitation — we are onboarding teams one at a time
Answer sheet
- Questions
- 21
- Answered from what exists
- 10
- Answered no
- 11
Something that exists Nothing to show yet
A What it produces
What does a plain-language description actually produce? A Rails app
A conventional Ruby on Rails application — not a no-code runtime and not a hosted DSL. The agent bootstraps the scaffold and writes ordinary Rails from there.
Where does the source code live? A GitHub repo
Every app is created with its own repository and real commit history. The agent commits its work to dev, and you can read every message and every diff.
Could our own engineers take it over? Yes
There is no proprietary runtime to unpick. It is Rails, deployed by GitHub Actions workflows that live in the repository with everything else.
How many stacks can we choose from? One
Rails only. A deliberate constraint rather than a gap — one stack is what makes the generated code predictable enough to trust unattended.
B How work reaches production
Who can put code into production? A person
Production is reached one way: someone opens Deploy and promotes dev to prod. The agent cannot do it.
Is every change recorded? Yes
Each change is a commit on dev carrying a message and a diff. History lists them in order, with the workflow run that deployed each one.
Is a deployment attributed to a named person? Yes
Each deployment is recorded against whoever triggered it, and that record is what the History surface reads from.
Are development and production genuinely separate? Yes
Separate deployments, each with its own database, its own logs and its own URL. Production is provisioned on request rather than by default.
C Access and governance
Is there single sign-on — SAML or OIDC? Not built
Sign-in is a one-time code emailed to your address. There is no identity-provider integration to configure.
Are there roles and permission tiers? Not built
Everyone signed in has the same access to the apps on their account. There is no viewer, editor or approver role.
Is there an audit log? Not built
No audit surface exists. What does exist is narrower and real: commit history for every change, and a deployment record naming who promoted it.
Are there organization or team accounts? Not built
Apps belong to an individual account. There is no shared team workspace and no seat management.
Can we choose where our data is stored? Not built
There are no data-residency controls. Generated apps deploy to Fly.io, and the platform's own records sit in a hosted Postgres.
Can we run this on our own infrastructure? Not built
There is no self-hosted or on-premises option. The repository is yours; the platform around it is not portable today.
D Certifications and references
Do you hold a SOC 2 report? No
Neither Type I nor Type II. No third party has audited this platform.
Are you certified to ISO 27001? No
No certification, and none in progress that we could point you at.
Do you have a GDPR or HIPAA attestation? No
Neither. The privacy policy states how data is handled — it is a policy, not an attestation, and we will not present it as one.
Can we speak to a reference customer? No
There are none to speak to. No customers, no pilots, no case studies, no benchmarks. You would be early, and that is the trade.
E Getting in
Can our team sign up today? By invitation
Signup requires an invitation. Attempts without one are recorded so we can come back to them as we onboard teams.
How does signing in work? Emailed code
Passwordless. A one-time code goes to your address, so there is no password for anyone to manage, reuse or leak.
Is there an enterprise agreement or procurement paperwork? Not yet
Plans and monthly credit allowances are published on the pricing page. There are no volume terms, no MSA and no security schedule yet.
Why the no answers are on the page.
ViberSpace is being built toward a platform an enterprise can clear — governance, access control, auditability. That is a destination, and section C is the honest distance still to cover.
What exists today is narrower and load-bearing. Apps are real repositories with real history. Nothing reaches production except a person promoting a branch. The code is conventional Rails your own team could adopt tomorrow. The compliance work gets built on those three facts, which is why we would rather publish the gap than describe it as a feature.
Tell us which answer you need changed.
We are onboarding teams one at a time, and what gets built next is decided by the reviews we fail. Tell us the app your team is waiting on, and the answer above that would block it.
Already invited? Sign in with the email your invitation was sent to