AI Roundtable Debate · 4 models
I want to explore using https://github.com/open-mercato for AI native clinic management software. Main use case for Open Mercato would be managing inventory and customers (pet owners). However, it would ideally support medical notes as well as pet charts.
Result: Unanimous — Use simple stack, serverless + Firebase (4/4 votes)
Options
- Use open Mercato (0 votes)
- Use simple stack, serverless + Firebase (4 votes)
Model Responses
Grok 4.1 Fast
Vote: Use simple stack, serverless + Firebase
Option B (simple stack, serverless + Firebase) offers superior flexibility for an AI-native clinic management software. Firebase excels in real-time data handling for inventory, customer (pet owner) management, medical notes, and pet charts, with built-in auth, Firestore for structured data, and seamless AI integrations like Vertex AI or OpenAI APIs. Open Mercato (A) is inventory-focused but lacks native support for medical notes or pet charts, requiring heavy customization. Its e-commerce roots make it mismatched for clinical workflows, potentially leading to security gaps and compliance issues in vet records. Serverless Firebase scales effortlessly for clinic growth, reduces ops overhead, and costs less for variable usage. Custom builds ensure HIPAA-like privacy for pet data and AI features like auto-generating notes from voice inputs. Choosing A risks project delays from forking an ill-fitting repo; B enables rapid prototyping and iteration for a tailored, future-proof solution.
Gemini 3.1 Pro
Vote: Use simple stack, serverless + Firebase
Using Open Mercato for a clinic management system is a classic case of domain mismatch. Open Mercato is fundamentally designed for e-commerce, marketplaces, and retail. Shoehorning complex veterinary requirements—like medical notes, pet health charts, and clinical workflows—into an e-commerce framework will lead to severe technical debt and constant workarounds. A custom serverless stack with Firebase is a far better approach for an AI-native application. Firebase's NoSQL document structure (Firestore) is incredibly flexible, making it ideal for storing unstructured, evolving AI-generated data, such as dynamic medical notes and complex pet charts. Furthermore, building a custom application allows you to tailor the user experience specifically to the daily workflows of veterinarians and clinic staff. Instead of fighting an existing framework to make it do something it wasn't built for, a simple serverless stack will allow you to move faster and build exactly what your users need.
GPT-5.4
Vote: Use simple stack, serverless + Firebase
Open Mercato appears oriented around commerce workflows: inventory, customers, catalog, orders, and marketplace-style operations. That overlaps with part of your need, but medical notes and pet charts are not just extra fields — they become core domain objects with clinical workflows, timeline views, permissions, auditability, attachments, and structured history. Adapting a commerce system to a veterinary EMR-lite product is likely to create friction fast. A simple serverless + Firebase stack is a better fit for uncertainty. Your requirements span inventory, pet owners, pets, encounters, notes, vaccinations, labs, reminders, and likely AI-assisted documentation. Those are custom data models, and Firebase gives you flexibility to evolve schema and workflows quickly without fighting an opinionated platform. It is also the safer product strategy for an early-stage AI-native clinic tool. You can ship the exact clinic workflows that matter first, then add inventory later, instead of inheriting a large codebase where only part of the surface area is relevant. In this case, building the clinic core cleanly matters more than reusing inventory/customer modules. Operationally, serverless keeps complexity lower. You avoid learning and maintaining a third-party monolith whose internals may constrain your roadmap. Firebase plus cloud functions is enough for auth, document storage, event-driven automation, role-based access, and AI integrations. The main argument for Open Mercato is speed on inventory and customer management. But because your differentiator includes medical notes and pet charts, the domain mismatch is significant. I would only choose Open Mercato if inventory/commerce is overwhelmingly the product center and clinical records are secondary. Based on your description, they are not. So my vote is B: start with a simple serverless stack and model the veterinary workflows directly.
Claude Opus 4.6
Vote: Use simple stack, serverless + Firebase
Open Mercato (https://github.com/open-mercato) appears to be a relatively obscure or early-stage open-source project. When evaluating it for something as critical as clinic management software — especially for veterinary clinics handling medical notes, pet charts, inventory, and customer data — you need a foundation that is reliable, well-documented, and actively maintained. The core use case described goes well beyond simple inventory and customer management. Medical notes and pet charts introduce domain-specific requirements: structured clinical data, SOAP notes, treatment histories, vaccination records, and potentially compliance considerations. Trying to bend a general-purpose marketplace or inventory tool into a medical records system will likely result in heavy customization that negates the benefit of using an existing framework. A simple serverless stack with Firebase offers several compelling advantages here. First, Firebase provides real-time database capabilities, authentication, and hosting out of the box — all essential for a clinic management app. Second, serverless architecture (Cloud Functions or similar) keeps costs low during early development and scales naturally. Third, you have complete control over your data model, which is critical when you need to design schemas for medical records, pet profiles, owner relationships, and inventory simultaneously. For the 'AI native' aspect, a custom stack gives you full flexibility to integrate LLM APIs (OpenAI, Anthropic, etc.) for features like AI-assisted medical note generation, smart inventory predictions, or natural language search across patient records. You're not constrained by another project's architecture or plugin system. Finally, building on well-established infrastructure (Firebase/GCP) means abundant documentation, community support, and battle-tested reliability — things you absolutely need for software handling medical data. The marginal time saved by adopting an unproven open-source project is not worth the risk and limitations it introduces.
Final Summary
The AI Roundtable reached a swift and unanimous verdict against repurposing an e-commerce repository for veterinary medicine, viewing the move as a recipe for immediate technical debt. GPT-5.4 and Gemini 3.1 Pro led the charge, arguing that medical notes and pet charts are complex clinical workflows that would be strangled by Open Mercato’s retail-centric architecture. Claude Opus 4.6 and Grok 4.1 Fast rounded out the consensus, noting that a serverless Firebase stack provides the necessary 'clean slate' to build AI-native features without fighting an opinionated, inventory-focused monolith.
All 4 models agreed on "Use simple stack, serverless + Firebase" after discussion
Strongest Arguments
- Use simple stack, serverless + Firebase: The domain mismatch argument: Open Mercato is built for transactions and inventory, whereas clinical software requires medical notes and charts to be core domain objects. Forcing a commerce engine to behave like an EMR creates a brittle system where customization costs quickly exceed any initial time savings.