---
title: Designing an ML Deployment API Around Best Practices
description: How GreatAI tried to make stronger ML deployment habits accessible through a small Python API.
date: 2026-05-09
projectPeriod: '2022'
thumbnail:
  src: ./_assets/great-ai.png
  alt: Example Python code using the GreatAI API.
tags: ['ai', 'systems', 'tools']
selected: true
featuredOrder: 1
project: great-ai
role: Researcher and framework author
stack: ['Python', 'ML deployment', 'API design']
scale: 33 deployment best practices, six proposed additions, evaluated with professional data scientists and software engineers
outcome: A Python framework, thesis, and research-backed API design for production-oriented AI deployments
audience: recruiter-relevant
links:
  - label: PyPI
    type: package
    url: https://pypi.org/project/great-ai/
  - label: Project site
    type: site
    url: https://great-ai.scoutinscience.com
  - label: MSc thesis
    type: thesis
    url: /media/downloads/great-ai-andras-schmelczer.pdf
    download: true
media:
  - type: image
    src: ./_assets/great-ai.png
    alt: Example Python code using GreatAI decorators and prediction helpers.
    caption: GreatAI's public surface was designed to keep deployment best practices close to the application code.
---

GreatAI started from a practical frustration: applying machine learning was becoming easier, but deploying it well was still easy to get wrong. Many failures were not about model architecture. They were about missing metadata, weak versioning, poor reproducibility, untracked inputs, or interfaces that made the right behavior too cumbersome to use.

My thesis work looked at that gap from two sides. First, I collected and organized AI/ML deployment best practices, including 33 practices and six additions proposed through the research. Then I designed a Python framework that tried to make those practices feel like the natural path rather than an enterprise checklist.

The result was GreatAI: a deployment-oriented framework with a deliberately small API. The design goal was not to wrap every part of an ML stack. It was to make common deployment concerns visible, automatic where possible, and hard to forget.

## The Problem

Deployment quality is often treated as something that happens after model development. That separation creates a bad default. A model can be useful in a notebook, but a deployed AI service also needs traceability, stable interfaces, input/output logging, model metadata, and operational behavior that can be inspected later.

The hard part is not listing those needs. The hard part is getting busy engineers and data scientists to adopt them without making their work feel slower.

So the core question became: can a framework implement meaningful deployment practices while keeping the API small enough that people would actually use it?

## Constraints

GreatAI had to satisfy two constraints that usually pull in opposite directions.

It needed to be robust enough to encode deployment practices such as metadata handling, model loading, request tracing, and reproducible prediction interfaces. But it also needed to be approachable enough that the basic use case still looked like ordinary Python.

That shaped the API. The framework could not demand a new mental model for every project. The deployment behavior had to sit close to the prediction function, because that is where the developer already has context.

## Design

The design leaned on decorators and lightweight conventions. The application author should be able to declare the prediction boundary, attach the relevant model and metadata behavior, and let the framework handle repeated operational concerns.

That is a careful tradeoff. Too much implicit behavior makes systems difficult to debug. Too much explicit setup makes best practices optional in practice, because the path of least resistance is to skip them. GreatAI tried to keep the implicit parts focused on cross-cutting deployment concerns rather than business logic.

Feedback from professional data scientists and software engineers supported the main premise: ease of use and functionality both matter when people decide whether to adopt deployment tooling. A framework that is technically complete but awkward to use will still fail.

## What Worked

The strongest part of the project was treating API design as part of deployment quality. Best practices are not only documentation. They need interface support, defaults, and feedback loops.

The research also forced the framework to be specific. "Production-ready" is too broad to be useful. A concrete list of deployment practices made it possible to ask which practices can be automated, which ones need explicit developer decisions, and which ones belong outside the framework.

## What I Would Change

If I returned to the project now, I would focus more on integration boundaries: how GreatAI should fit into modern observability, model registry, and evaluation workflows without trying to own them. Deployment frameworks age quickly when they become too broad.

The part I would keep is the central idea: make the right deployment behavior easy enough that it becomes the default.
