Bringing Practical AI Into a SaaS Product: The Firepanel Case Study

What Firepanel actually does

Firebase gives developers strong infrastructure: authentication, a database, storage, hosting. What it doesn't give them is a way for anyone else on the team to manage content without touching raw Firestore documents. Firepanel is the missing layer: a Firebase CMS and admin panel where developers and their teams or clients manage content types, collections, storage, users, search and notifications through a visual interface. It stays headless, so the frontend keeps running on whatever stack the team already uses, React, Next.js, Flutter, Vue or otherwise.

That interface alone solves a real problem. But even with a better console, developers still repeat the same setup and maintenance work on every single project. That repetition, not a desire to “add AI,” is where Yetiman started.

Generating content types instead of defining every field by hand

Before a Firebase app can do anything, someone has to decide how its data is structured: what collections exist, what fields each one holds, what type each field is, and how everything relates. This is content modeling, and it's predictable work that still takes real time to type out field by field.

Firepanel already analyzes existing Firestore collections and proposes matching content types automatically. For new projects, Yetiman and Firepanel added Generate with AI: a developer describes what they need in plain language, for example “a blog with posts, authors and categories,” and Firepanel uses Vertex AI with Gemini, running inside the customer's own Google Cloud project, to interpret that description and propose collections, subcollections or reusable components. The developer reviews and adjusts the fields before anything is used.

The point isn't to take the developer out of the loop. It's to remove the blank canvas. Instead of building a predictable structure from nothing, the developer starts from a generated draft and spends their attention on the decisions that actually need a human, not the ones that don't.

The upside isn't only speed, either. A manually typed schema is exactly where small mistakes creep in: a field called customerName in one collection and client_name in another, a date stored as plain text instead of a proper date type, a typo that only surfaces once the frontend breaks. Because Firepanel proposes the full structure from a single description, naming stays consistent across collections and each field gets the type the data actually needs, without a developer re-checking every entry by hand. It also changes who can start the process: someone who has never modeled a NoSQL database, a product manager or a content lead, can describe what they need in plain language and hand a developer a structure to review, instead of waiting for someone to translate the request field by field.

Turning an empty collection into realistic sample data

A new collection with three manually typed test records doesn't tell a team much. To see how an interface actually behaves, developers need enough realistic data to expose long titles, unusual values, larger lists and edge cases they didn't think to design for. Creating that data by hand is exactly the kind of task that eats an afternoon without producing anything a client will ever see.

Generate Sample Data turns that afternoon into a prompt. Once a content type exists, the developer picks how many documents to generate and can add guidance for a Blog Post type, something like “Technology articles about AI, published in 2026.” Firepanel generates structured records that respect the content type and writes them directly to Firestore, leaving media, references and relations that need extra configuration for the developer to finish.

The payoff shows up before launch, not after. Realistic datasets make it possible to test pagination, filtering, search, empty states and general UI behavior while there's still time to fix what breaks. For prototypes and demos, it also means going from an empty database to something that looks like a working product in far less time.

Ask Firepanel: querying Firestore in plain language

Generating structure and data solves two problems. The third is simpler and comes up constantly: understanding data that's already there. Ask Firepanel, currently in beta, is a read-only assistant for exploring Firestore using plain language instead of manually opening collections, inspecting documents and assembling queries to answer a question.

A developer can ask things like “how many documents are in each collection”, “show me the 10 most recently created records”, “which content has changed the most this month” or “summarise the data available in this project.” The assistant explores accessible documents, spots patterns and calculates metrics, and it deliberately stays read-only. That restriction is the design decision that matters most: the goal isn't an autonomous agent with unrestricted access to a production database, it's a conversational layer that helps developers investigate and understand their data faster while staying fully in control of what changes.

Because the questions are asked in plain language rather than a query syntax, someone with no Firestore or database background, a PM checking on content status, a support lead investigating an issue, can get an answer directly, instead of waiting on a developer to write and run a query for them.

What this actually saves: time and money

The clearest way to judge these features isn't by counting what AI can generate, it's by counting the repetitive work it removes, and that work goes well beyond typing fields into a form. Take a medium-sized Firebase project with around 20 content types: some are simple, a Tag or an Author, others are considerably more work, a Product with variants, media and several nested relations to other collections:

Defining the structures is only the start. Teams still spend real time in meetings aligning on naming and relations before anyone writes a line of code, then more time later fixing the inconsistencies that slipped through, and still more cross-checking that every reference between collections actually points where it should. With Firepanel's AI features handling the first draft and enforcing consistent naming and types from the start, a workflow that would otherwise take 37–65 hours, well over a working week, drops to about 4.5–9.5 hours of generation, review and refinement.

These figures are indicative, not measured benchmarks; the actual saving depends on project complexity, team size and how much manual configuration and alignment the project would otherwise require. Using a €50/hour internal or billable development-cost assumption, 33.5–55.5 saved hours works out to roughly €1,700–€2,800 on a single medium-sized project. At a €100/hour agency rate, the same reduction becomes roughly €3,350–€5,550 in potential production cost avoided.

None of this is a one-off saving, either. Sample data gets regenerated for new environments. Content models change as products evolve. Developers inspect databases repeatedly during QA, debugging and feature work, and teams keep having the same alignment meetings on every new project. Across multiple Firebase projects, these reductions in repetitive work and rework compound, which means the real value isn't that one action gets faster, it's that the team stops repeatedly spending expensive development time on low-value manual work, meetings and fixes that a consistent first draft would have avoided.

AI works best when it removes friction

The features built for Firepanel reflect how Yetiman approaches AI in digital products generally: not every workflow needs an agent, not every interface needs a chatbot, and adding generative AI to a product doesn't automatically make it better. The useful question is narrower: what is the user repeatedly spending time on that a machine could reasonably do for them?

In Firepanel, the answer was specific. Developers were defining predictable content structures by hand, so AI creates the first draft. They were manually filling databases with test content, so AI generates it. They were navigating data to answer relatively simple questions, so an assistant retrieves and summarizes it. In every case, the developer still reviews the structure, validates the generated content and decides what happens next. AI handles more of the repetitive work surrounding development, which frees developers to spend more of their time actually building the product. That's the point where AI stops being a feature on a list and starts acting as infrastructure for a better workflow.

Generate with AI and Generate Sample Data are, in effect, AI automation copilots built directly into a developer tool. Ask Firepanel follows the same discipline Yetiman applies when building AI chatbots for other businesses: a conversational layer with clear boundaries on what it's allowed to touch, not an open-ended agent.

The next step

The highest-return AI features are rarely the ones with the flashiest interface. They're the ones that quietly remove a task nobody wanted to keep doing manually. Before adding an AI feature to your own product, list the three or four tasks your team repeats on every single project, then ask which of them a machine could produce a reviewable first draft of, not a fully autonomous replacement. That's the entire model behind Firepanel's AI features, and it's worth testing on your own workflow before building anything more ambitious.