SalonAI — a salon platform I built with a seven-person team — needed to recommend hairstyles across six face-shape profiles and estimate pricing. Generic prompting got us demos, but not the consistent, domain-specific behavior a product needs. So I fine-tuned a LLaMA model and shipped it as a real service.
Why fine-tune instead of prompt?
Prompting is the right first move — it's fast and free to iterate. But for structured, repeatable, domain-specific output, prompts get long, brittle, and inconsistent. Fine-tuning bakes the behavior into the weights: shorter prompts, steadier outputs, and a model that already "knows" the task.
LoRA: fine-tuning on a budget
Full fine-tuning of a 7B/13B model is expensive and memory-hungry. LoRA (Low-Rank Adaptation) freezes the base weights and trains small adapter matrices instead — a tiny fraction of the parameters. That let me fine-tune LLaMA 7B/13B on 2× NVIDIA V100 GPUs without renting a cluster, and keep the adapters swappable.
Shipping a model, not a notebook
The hard part of "AI" is usually the engineering around it. I served the model as a dedicated AI microservice behind a clean contract: a React / React Native client talks to a Django REST backend, which calls the AI module over REST/gRPC. Around it: role-based access control across three roles, JWT auth, bcrypt, and 12 Pydantic validation schemas to keep inputs sane when an LLM is in the loop. Three services, containerized with Docker Compose and orchestrated on Kubernetes.
What I took away
- LoRA makes fine-tuning accessible — you don't need a data centre to specialize a model.
- Treat the model as a service with its own API contract, validation, and scaling story.
- Guard the inputs. Schemas and auth matter more, not less, when a model is making decisions.
Applied AI is 20% the model and 80% the system around it — and that's exactly the part I enjoy building.