AI Research Management Platform
Designed and built LLACE, a full-stack platform for managing the lifecycle of AI models in healthcare research, from project organization and model versioning to deployment, built in collaboration with UMCG.
- ▸Full-stack platform with React frontend, PocketBase backend, and Flask proxy for model deployment via UbiOps
- ▸Requirements gathered through interviews with UMCG researchers, user-driven design addressing real healthcare AI workflow gaps
- ▸Modular architecture with advanced search across projects, models, publications, and researcher profiles
- ▸Scoped with MoSCoW prioritization: shipped a working MVP (React, PocketBase, Flask, UbiOps) and documented a production architecture as a blueprint for future work
Overview
Grade: 8.5 / 10 | BSc Thesis in Computing Science | Supervised by Prof. Dimka Karastoyanova and Michel Medema, MSc.
My Bachelor's thesis at the University of Groningen, built in collaboration with the University Medical Center Groningen (UMCG). Researchers at UMCG were working in isolation: AI models stored locally, no shared infrastructure for collaboration, and no convenient way to discover or deploy each other's work despite using the Habrok HPC cluster for computation.
LLACE (named after Ada Lovelace) addresses this by providing a centralized platform for the entire AI model lifecycle in healthcare research: project organization, model versioning and metadata, deployment, and cross-team discovery.
Requirements & Process
The design was driven by interviews with eight UMCG researchers to understand their actual workflows and pain points. I used MoSCoW prioritization to scope requirements into must-have, should-have, could-have, and won't-have categories, essential given the fixed thesis timeline.
Key requirements that emerged:
- Researchers needed to discover what others were working on (models, datasets, publications)
- Models needed proper versioning and metadata tracking through their lifecycle
- Deployment should be accessible without deep DevOps knowledge
- The platform must comply with healthcare data security and privacy standards
- Integration with existing infrastructure (Habrok HPC, institutional repositories like Pure)
What I Built
User & Project Management
- Account creation with role-based permissions (researchers, administrators)
- Research project organization with collaborators, descriptions, and linked resources
- Profile management for researcher discovery
AI Model Management
- Version control and metadata tracking for AI models
- Model upload and configuration interface
- Deployment to UbiOps directly from the platform: researchers deploy models without managing infrastructure themselves
Advanced Search
- Multi-faceted search across projects, models, researcher profiles, and publications
- Filter by type (models, projects, profiles, publications) with tag-based categorization
- Enables cross-team discovery of relevant work within the institution
Project Pages
- Detailed project views with description, metadata, collaborators, and linked models/publications
- Related projects and models surfaced automatically for cross-team discovery
Architecture
I designed two architectures: an ideal production system and a feasible MVP for the thesis scope.
Ideal architecture (documented as a blueprint for future development):
- React frontend → NGINX API gateway → Django business layer with multiple service modules
- Redis caching, PostgreSQL database via Django ORM
- Integration with UMCG systems, LDAP/OAuth authentication
- Kubernetes for orchestration and scaling
MVP architecture (what I implemented):
- Frontend: React with standard component/page/hook structure, communicating via Axios
- Backend: PocketBase (embedded database, built-in auth, REST API) handling most data operations
- Flask proxy: Dedicated backend for deployment requests to UbiOps
- UbiOps: External platform providing computational resources for model execution
This separation keeps the MVP lean while the ideal architecture serves as a roadmap for production scaling.
Challenges & Tradeoffs
- Scope vs. ambition: The ideal architecture is significantly more complex than what's feasible in a thesis. Choosing PocketBase over Django + PostgreSQL meant sacrificing some flexibility but enabled a working prototype within the timeline
- Healthcare compliance: Even for an MVP, data security considerations had to be baked in from the start, not bolted on later
- User interviews vs. assumptions: My initial assumptions about what researchers needed were wrong in several places. The interviews reshaped the feature priorities significantly
- Modularity for handoff: Since UMCG might continue development, I prioritized clean separation of concerns and extensibility over feature completeness
Results
The MVP delivers a functional platform covering user management, project and model lifecycle management, search/discovery, and model deployment. The modular architecture ensures it can evolve toward the ideal production system as resources allow.
The thesis documents both the platform implementation and the full ideal architecture as a blueprint, positioning LLACE as a foundation that UMCG can build upon.
What I Learned
- Interviewing actual users before building anything pays off: the gap between what you assume researchers need and what they actually need is significant
- Designing both an ideal and constrained architecture forces you to understand which abstractions actually matter vs. which are premature
- PocketBase is effective for prototyping: an embedded DB, auth, and REST API in a single binary eliminate a lot of setup friction
- Writing a thesis that satisfies both technical implementation and academic writing requirements is its own skill: it means balancing depth of detail against readability