Work Stately Cloud
StatelyDB: Designing Schema-First
A schema-first database with a complex core model. My job was to make it legible.
00. tl;dr
- Context
Schema-first intelligent data platform with a powerful core model, but no equally clear way to explain or onboard into it.
- Role
Independent design partner across product, brand, and web - from research and identity to design systems and shipped interfaces.
- Work
Reframed the product around a schema-first model, shaped core UX, and built the design foundation across brand, product, and web.
- Impact
Made a hard-to-explain technical model understandable on first contact. Stately Cloud was acquired by Databricks in 2025.
01. Intro
StatelyDB's value was technical, but the design problem was clarity.
StatelyDB is a database for backend developers - schema-first, strongly typed, version-safe, and built around a complex technical model. Its value lived in how schemas were defined, published, and connected to application logic.
That complexity shaped the work from the start. Before designing anything, I needed to understand how the product behaved, where it broke down for users, and what made it difficult to explain.
02. Core logic
The product only made sense once the schema lifecycle made sense.
The core value lived in the schema: define it, publish it, bind it to a store, generate a strongly typed SDK. Publishing a new schema version changed nothing until the developer regenerated the SDK. If a key path changed, a migration ran automatically. If it did not, nothing changed.
That logic made the product powerful, but also hard to grasp on first contact.
I started by using the CLI as a real user would - going through setup, hitting the same dead ends, reading the same unclear messages, and documenting the same confusing states a new developer would run into.
One of the co-founders put it plainly:
We really suck at explaining this concept today.
That became the real brief.
03. Research
The product started with stores. Developers started with schemas.
To ground the product direction in real developer behavior, I ran directional interviews with 7 senior and staff engineers focused on schema management pain - not on StatelyDB itself, but on the underlying problem space.
A clear pattern emerged. Every engineer had experienced breakage after schema changes. Most said that, when starting a new project, schema definition would come before almost anything else.
That insight exposed a mismatch in the product structure. The console treated the Store as the primary object - create a store first, then attach a schema. Developer mental models pointed in the opposite direction.
I used that research to propose a schema-first structure, with schema creation as the entry point and store creation as a downstream step. I documented the recommendation as an IA map, a decision tree covering three onboarding paths, a separate store creation flow, and a set of product questions the UX could not answer until the product logic was resolved.
That meant reversing the product structure: schema first, store second.
04. Three phases
The business went through three distinct shifts in direction. Each shift changed the brief, but the same foundations carried through.
Phase I: Credibility
The first priority was external credibility.
I established the initial brand foundation - color system, typography, brand guidelines, and a rebuilt logomark with proper geometric construction and usage rules. That work extended into investor and partner-facing materials that made the company look coherent and credible.
During this phase, I built the first full design system spanning both product and marketing, and designed the first full console iteration on top of it.
The goal was not to make the company louder. It was to make it feel real.
Phase II: Differentiation
By the time the foundation was in place, Stately had credibility. But credibility alone doesn't differentiate. In a category dominated by serious, enterprise-feeling database tooling, looking professional is table stakes, not a moat. The product needed to feel distinctly itself.
The direction was a deliberate aesthetic shift: neobrutalism paired with rubber hose illustration. Thick black strokes, pill-shaped buttons that read like stickers, oversized type set in sharp contrast, halftone textures, and a saturated pink-yellow-green palette - balanced by warm, hand-drawn cartoons in the bendy 1930s tradition. The combination kept the structure confident and engineered, while making the brand feel handmade instead of corporate.
I carried the structural foundations from Phase I forward, layering in recurring motifs - cloud environments, science-notebook doodles, and a playful illustration layer - that gave the system more presence.
The same visual language had to work across the website, product surfaces, onboarding, blog, comparison pages, investor materials, and developer-facing explanations. The goal was to make Stately more recognizable without making the product feel less serious.
The mascot itself was illustrated by Kendall Hale. Around it, I shaped the supporting illustration system - sketching elements like clouds and doodles, defining recurring motifs, and deciding where illustration could support the product without getting in its way. Kendall then reworked those elements in the same visual language as the main character, giving the illustration layer a consistent style.
The result was a visual language that gave Stately more presence across product and marketing, while keeping the system grounded in the same technical foundation.
Phase III: Enterprise
The final shift was toward enterprise. As the audience for Stately matured - moving from curious individual developers toward technical buyers and CTOs - the brief became much more direct: remove anything that might introduce hesitation in a serious procurement conversation. The character system, the playful illustration, the saturated palette - useful for differentiation, but a liability the moment the evaluation needs to clear a CTO-level technical review.
That meant simplifying the expression, not restarting the work. I stripped back the personality layer, kept the useful foundations from the previous two phases, and rebuilt the system into a denser, stricter framework better suited to enterprise use. Less air, tighter spacing, more information per surface, sharper hierarchy. The same engineering thinking, expressed more soberly.
Because the foundations from Phase I were structural, not decorative, the transition was simplification rather than reconstruction. The system carried forward intact - only the surface expression had to change. That distinction is the whole reason Phase III was a quiet evolution and not an emergency redesign.
What was keptThe logotype, the color anchor, the geometric construction, the proportional system.
What was droppedClouds, mascot, illustration scenes, sticker-style UI elements, halftone textures, the warmer accent colors.
The output didn't feel like a different brand - it felt like the same brand, grown up.
05. Scope
Fractional sole designer across brand, product, and web.
Three console iterations, three website generations, and one design system built to evolve across all three phases. The final marketing site was built solo in Webflow.
Edge cases, error states, stale states, and small hidden product trust gaps included. No agency, no handoff, no design theatre.
06. The product
The product work turned schema-first logic into a usable developer workflow.
The console went through three major iterations across the engagement, each grounded in the previous round of learning and product refinement. Two product areas carried most of the complexity.
The first was first contact. A schema-first database is conceptually unfamiliar, and developers arriving for the first time needed an interface that taught the mental model while getting them productive. The quickstart structured that into four explicit steps, so the abstract pieces had a concrete sequence to attach to.
The second was helping developers get past the blank page. Even when the model made sense conceptually, writing a first schema from scratch was its own friction point. The creation flow met developers at three entry points - paste existing data, build step by step through a guided interface, or stay in the terminal with the CLI. The Schema Architect was the deepest of those paths: a guided conversation paired with a live code preview that built up the schema as the developer answered.
Once developers had multiple schemas in flight, the dashboard became the workspace - status, store bindings, latest versions, ownership, and recency. The work was not about flattening the product into something generic. It was about making a complex model usable without misrepresenting how it worked.
07. Outcome
The product was designed so schema changes would not break applications. I built the design foundation so business changes would not break the experience.
Across three business pivots, three console iterations, and three generations of the website, the design foundation I built held without rebuilding. One system, one brand, one set of structural rules - flexible enough to evolve from approachable startup voice to enterprise restraint without disconnecting from itself.
I reframed the product around a schema-first model and clarified the logic of versioned schemas in the UI. A hard-to-explain technical model became something developers could reason about on first contact, without consulting docs in a second tab.
In December 2025, Stately Cloud, the company behind StatelyDB, was acquired by Databricks.
Read the Databricks announcement (opens in a new tab)