Add project writeups

src/content/posts/greatai-ai-deployment-api.md

@@ -0,0 +1,71 @@
+---
+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']
+featuredOrder: 1
+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
+    url: https://pypi.org/project/great-ai/
+  - label: Project site
+    url: https://great-ai.scoutinscience.com
+  - label: MSc 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 behaviour too cumbersome to use.
+
+My thesis work looked at that gap from two sides. First, I collected and organised 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 behaviour 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 encode deployment practices such as metadata handling, model loading, request tracing, and reproducible prediction interfaces. It also had 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 behaviour 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 behaviour, and let the framework handle repeated operational concerns.
+
+That is a careful tradeoff. Too much implicit behaviour 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 behaviour easy enough that it becomes the default.