REFERENCE TABLE · RT-001
The Vibe Codeability Database
Every app on the register gets its Vibe Score from the same fixed parts catalog: tag which of these components its rebuild actually needs, average their ratings. 100 means an agent one-shots it without thinking. 0 means don't bother.
Component ratings
20 components on file| component | vibeability |
|---|
| Landing page | 99 |
| Contact form | 98 |
| CRUD database | 95 |
| User login | 92 |
| Email notifications | 91 |
| Stripe checkout | 88 |
| File uploads | 87 |
| Search | 86 |
| Google Maps | 80 |
| OAuth | 77 |
| OS-level integration | 72 |
| Realtime collaboration | 67 |
| Browser extensions | 64 |
| Native iOS | 61 |
| Complex calendar sync | 58 |
| Stripe Connect marketplace | 52 |
| Video processing | 45 |
| Live video / WebRTC | 35 |
| End-to-end encryption | 28 |
| Custom canvas/rendering engine | 15 |
How a Vibe Score is built
- Every app's sheet lists which components its specific build prompt requires — not every feature the real product has, just what our prompt actually builds
- The score is the plain average of those components' ratings, rounded to the nearest whole number
- More components isn't automatically worse — a login screen (92) barely dents an average; end-to-end encryption (28) drags one hard
What the score can't see
- Non-technical moats — network effects, legal weight, an ecosystem of plugins — don't show up here. A high score can still land on a JUST PAY stamp for exactly that reason
- Component interactions compound: OAuth plus realtime collaboration plus a marketplace is harder than the three numbers averaged suggest
- The catalog covers common web-SaaS building blocks. Genuinely novel engineering — a custom rendering engine, say — has no entry yet, and a score built without one will read too optimistic
← see the score applied on the register