Building an AI Assistant for Junior Tennis Parents
DBB Software ran product discovery and built the MVP of an AI assistant that plans a junior tennis player's tournament season through conversation, taking a parent from a first question to a shortlist ranked by level, travel distance, and dates. The build is ongoing ahead of release.
Industry
Technology
Service
Agentic AI Development
Team
1 AI Engineer, 1 Back-End Engineer, 1 Data Engineer, 1 Front-End Engineer, 1 DevOps Engineer, 1 QA Engineer, 1 Team Lead
Project State
June 2026 - Ongoing
Country
United States
About the Client
The client is a United States technology company building a tournament-planning product for junior tennis. Its users are the parents of competing juniors, who carry most of the planning burden themselves: reading federation calendars, checking eligibility and entry requirements, and working out travel before entering anywhere.
The Client's Initial Request
The client engaged DBB Software to run product discovery and deliver the MVP, because finding the right tournaments for a child means cross-reading federation calendars and eligibility rules by hand before travel is even considered.
Tournament Discovery in One Place
Bring events from more than one sanctioning body into a single answer, so a parent stops moving between federation websites.
01
Recommendations Matched to the Child
Match suggestions to a player's level and to how far the family is willing to travel.
02
Journey Planning Across Several Events
Suggest consecutive tournaments that can be played on one trip, so a season's travel is planned as a run of events.
03
Discovery Through to a Working MVP
Take the product from scoping to a delivered build, with the client's team retaining design.
04
Solutions We Delivered
DBB Software ran discovery and built the MVP with a seven-person team spanning AI, back end, data, front end, DevOps and QA. The assistant is built on the Mastra agent framework over PostgreSQL with pgvector, and its shape changed during the build: what began as a staged workflow became a single agent holding its own tools.
A Single Agent With Tools
The proof of concept ran three steps in a fixed order: a plan step, a retrieve step, then a synthesis step.
The retrieve step was capped at three queries against the document store. That budget proved unreliable in practice and absorbed a large amount of tuning.
As testing widened, a single agent holding tools it calls at will performed better on the same conversations.
The change retired both the plan step and the retrieval budget, leaving the agent to decide how much evidence a given question needs.
Models Tested and Models Shipped
The assistant has run on three model families, and the change of architecture drove the change of model.
The staged proof of concept split the work by role: a Haiku model planned, and a Sonnet model handled retrieval and synthesis.
Xiaomi MiMo v2.5 and v2.5 Pro were trialled between the two designs and did not carry through.
GLM 5.3 Flash was trialled during development and dropped.
The single-agent build runs on GLM 5.3, which performed better once the agent chose its own tool calls.
Three Tools the Agent Calls on Demand
The agent reaches data through three named tools and chooses when to use each.
count_tournaments returns how many tournaments sit in each city across a date range, which lets the agent see where a season's options concentrate before naming any single event.
query_tournaments returns the tournaments themselves for a date range, sorted by proximity to the family's home.
query_documents retrieves written material behind a question rather than calendar rows.
Retrieval Over Tournament Regulations
query_documents embeds the parent's question and pulls the documents closest to it: current tournament regulations, rule changes, and newly published information a calendar entry does not carry.
Embeddings come from Voyage AI's voyage-4-large, held in pgvector alongside the tournament data.
voyage-context-4 was evaluated as an alternative, since it embeds each chunk with a view of the others and is reported to improve on the general model. The team stayed on voyage-4-large to keep the retrieval path simple.
Chat Onboarding for Parent and Child
The assistant collects what it needs by asking for it over the course of the conversation.
A parent opens with something as loose as a request for tournaments for their daughter, and the assistant asks for the missing piece it needs first.
Home location comes first, because travel radius and proximity reasoning depend on a home base before anything else can be ranked.
The child's profile is assembled over the conversation rather than entered up front, which suits a first-time user who has no account history behind them.
Eligibility Confirmed Against the Player
A tournament reaches the shortlist once the child actually qualifies for it.
The player's age, level and location are confirmed against what the event itself requires.
Level and location carry the most weight, alongside how far the family will travel and the date range they are planning around.
Geocoding From Federation Data
Distance is computed from coordinates rather than estimated from place names.
Where ITF and USTA public resources already carry coordinates for a venue, those are reused directly.
Where a venue has none, a Google Places lookup fills the gap. Venues are far fewer than tournaments, so that fallback is priced per venue rather than per event and stays inexpensive.
Scenario Testing on Known-Eligible Fixtures
Recommendation quality is checked against cases where the right answer is established in advance.
Test users are built with different player details: age, level, home location and travel radius.
Each run confirms the assistant returns tournaments already known to be eligible for that player.
The MVP Platform Around the Assistant
The assistant sits inside a full product build, delivered from discovery through QA.
Tournament data is drawn from USTA and ITF. Player details are captured through the assistant rather than imported.
A React single-page application front end runs against a NestJS back end on Google Cloud, with parents signing in through their Google account.
Grafana and Sentry were wired in during the build for metrics, observability and error logging.
Results Achieved
A Profile Built in Conversation
The assistant asks for a child's details across a chat, so nothing depends on a completed form.
Fewer Parts to Tune
Retiring the plan step and the fixed retrieval budget left 1 agent deciding what evidence it needs.
Current Rules in the Answer
Regulation changes and new guidance reach a parent through retrieval, not only the calendar listing.
Real Distance From Home
Geocoded coordinates let the assistant sort events by how far a family actually travels.
2 Circuits in 1 Shortlist
USTA and ITF events reach a parent in the same answer.
Instrumented Before First Users
Metrics, observability and error logging were built in, so the MVP reaches release already measurable.
Turn Your Catalog Into a Conversation
DBB Software builds AI assistants that read your own data and return answers a customer can act on.
Contact Us
"Most of our work starts with a 30-minute call where someone describes a product they're trying to ship and one part of the engineering picture they can't get around.
If that's where you are, let's set one up; I'll tell you straight whether we're the right fit.”
Mina Morkos
Business Development Manager
Want a similar outcome for your team?
Ask our AI assistant — it can pull related case studies, talk through the approach, and put you in touch with the team if you want a deeper conversation.
