Outcome
- 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
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.
What this means for AI product design
Chat-only AI interfaces work well for short, completable interactions, write me an email, summarise this document, answer this question. They stop working when the artefact is structured and large enough that the user needs to see and touch it directly: a database schema, a contract draft, an org chart, a project plan.
For those cases, the design problem is the seam: how the chat output lands somewhere the user can actually own. In Ninox, that seam is the data-model editor: the AI generates into it, and the user picks up editing in it. The chat doesn't disappear; it stops being the only path. That coexistence is what made AI-assisted onboarding feasible for users who couldn't have written the spec themselves and wouldn't have managed the schema through chat.
The same seam will matter wherever AI is used to onboard non-experts into a structured artefact, legal AI included. The user needs the document, not a chat transcript about the document.
Read the full case study
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.
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.
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.
The design principle behind it
The underlying principle isn't unique to databases. It applies to any AI-generated artefact that a human has to take ownership of.
The AI's job is to reduce the blank-screen problem. The hardest part of building a database from scratch, especially for a first-time builder, is starting. AI solves that. But once the screen has content, the user has to feel immediately in control of it, or the AI has just moved the problem: instead of staring at a blank screen, they're staring at someone else's database.
For an SME owner, a partner at a small law firm, the dispatcher at a roofing company, the schema needs to belong to them within a few minutes of seeing it. That ownership shift is what makes the rest of Ninox's power available to them. Auto-magical interfaces only feel magical if the data model underneath is yours.
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? Get in touch.