Who Controls the AI?
A founder-led stealth project to extend Ninox's reach. The platform is incredibly powerful once a schema exists, but defining the schema was the gate that kept most non-technical SMEs out. Prompt-to-database generates a schema from a plain-language description. The design problem: how to hand a non-database-savvy user a schema they can actually own.
The Context
Ninox is a no-code business application platform, people build their own ERP systems, project trackers, case management tools and data apps without writing code. Its superpower (and its hurdle) is that it is database-first. Once a schema exists, Ninox auto-generates rich interfaces, applies direct manipulation everywhere, and the document/record mentality fits SME workflows perfectly, law firms, construction companies, contractors, inspectors, the kind of business where every job is a record with attachments and statuses.
View full size ↗ The entry point: describe what you want to build. The right panel is empty until the AI generates something.
That database-first design is also what kept Ninox's most successful customers in a narrow band: people who already had some database knowledge, or businesses that hired a consultant to set the platform up. The prompt-to-database initiative was meant to extend the reach. Generate the schema from a plain-language description, and people without database training can cross the gate that previously stopped them.
I worked on this directly with Ninox's CEO and technical co-founder in a stealth pre-product-team phase, a founder-level exploration of how onboarding for this should feel. The engineering of the AI generation was being handled separately. My question was the harder one: what happens after the AI shows you what it built, when you are a non-technical SME owner who has never thought about tables and relations before?
Why chat alone wouldn't work
The obvious AI-onboarding pattern is a chat interface: user describes the database, AI replies with the schema rendered as text or a structured response, user asks for changes in chat, repeat. That pattern breaks here in two ways that aren't theoretical.
Read the reasoning behind this decision
Long chat outputs don't scale to schemas
A realistic SME database has eight or twelve tables, each with ten or twenty fields, plus relations. A chat that prints that schema back to the user, and then expects the user to type 'change the `Customer` table's `phone` field to a multi-value field, and add a `country` field after it', is going to feel like writing migration scripts in prose. The schema is large enough that the chat transcript stops being a conversation and starts being a wall of generated text the user has to navigate.
Trial users won't write a long spec upfront
The other end of the conversation has the same problem in reverse. A trial user is not going to type a 400-word spec into the first prompt: 'I need a CRM for my law firm with clients, matters, case files, billing records, deadlines, contact people per client, document attachments per matter…' They will type one sentence. The first AI-generated schema will be off by at least a little, sometimes by more. Recovering from that mismatch through additional chat turns leads back to the first problem.
Both constraints together meant chat alone was not a viable interaction model. The schema had to live on a surface the user could see and touch directly.
Design decisions
-
Schema renders into the real data-model editor
The AI doesn't produce a chat-rendered preview of the schema; it generates directly into the same data-model editor a user would touch to build a database manually. Tables appear as cards, fields are clickable, relationships are drawn as arrows. The user sees what they would normally see, just generated, not built by hand.
-
Direct manipulation as the primary path; chat as the alternative
Every table card has 'add field' and 'edit' affordances right there. Users can add fields, rename them, change types, add or remove entire tables without opening the chat. Chat stays available for changes that are easier to describe than to click, but the user picks which path matches the change they want to make. Both paths converge on the same schema.
-
First-schema-is-wrong, handled gracefully
Because the first prompt will be short and the first schema will be off, the design accepts that as the normal case. Suggested-actions chips below the chat propose obvious additions ('add SLA tracking to tickets', 'add escalation flags to agents'). The user doesn't have to remember everything they want, the AI keeps proposing, the user keeps editing, and the schema grows incrementally.
-
The schema, once built, is just a Ninox app
There is no separate 'AI mode' the user has to leave. Once the schema feels right, they click into the app and start using it, same builder, same sidebar, same edit affordances they have just used. The prompt-to-database generation step folds into Ninox's normal authoring surface; it doesn't replace it.
Outcome
The 'show the schema, let the user edit it directly' principle became the spine of the AI onboarding when the work transitioned from founder collaboration to product-team build-out. The strategic point, that direct manipulation has to coexist with chat, not be replaced by it, set the interaction model for the beta.
- Engagement scope
- Founder-led stealth phase; design handed off to the product team as the basis for the public Ninox AI platform (beta 2026)
- Interaction model
- Split-screen direct manipulation alongside chat: adopted as the primary onboarding pattern
- Audience reach
- Designed to make Ninox usable for SMEs without database knowledge, law firms, construction, contractors, inspectors, where setup previously required a consultant
Want to hear more?
- The AI's first guess at your schema is almost always a little off. Curious why the fix was never a smarter chatbot, but making sure a law-firm partner who's never thought about tables and relations doesn't have an 'AI mode' to escape from?