AIdeas: DadBot - An AI assistant to stay healthy and slay the dad bod. Not just for dads!
DadBot is ready to take personalized lifestyle coaching to the next level. DadBot features personalized machine learning models and self-adjusting lifestyle coaching powered by AWS Bedrock. And it's almost completely serverless!
App category
Daily Life Enhancement
My vision
Calorie tracking, fitness, and lifestyle coaching apps all require the user to continuously log information, often entering it by hand. Hardly any apps offer a natural language interface (free text) and most are not pro-active with sending reminders, nor offer any meaningful personalization.
In my vision that is something that should be changed.
Most lifestyle change methods are one size-fits all, while humans certainly aren’t. In practice this means people tend to try out multiple things before finding something that works for them. In my ideal world we’d all have a pocket health coach that can fall back on personalized recommendation and prediction algorithms to figure out what works best and what our progress is going to be over time. Often folks are more than willing to change their life to lose (or gain!) weight, but are not being coached or approached in the right way. I want to have as few barriers as possible to prevent this.
So I built DadBot, the agentic AI health coach. DadBot can communicate with users on apps they already use, like WhatsApp, Signal, Telegram or Discord. DadBot can get in touch with users several times a day to brief them on how their day is going to look like and will suggest a workout based on things like weather conditions, the user’s calendar, their workout preferences and their recent workout history.
Users can also interact with DadBot and log their workouts/activities, their weight stats, their meals/calories and even update their profile through simply chatting with DadBot.
The name DadBot was chosen as a playful word play on “Dad Bod”, an informal name for the stomach fat often accumulated after becoming a dad.
Why this matters
In most of the western world high body weight levels are increasingly becoming problematic. In my own country of The Netherlands, about 50.4% of the population is now overweight (2024 data) . A lot of the people who are already overweight are not yet in sight of traditional health care providers and do not want to. An low-fuss, low threshold method for them to follow a personalized workout routine would be an ideal way to coach them
Personalized coaching of course exist and is very lucrative in a sense that a personal trainer or life style coach can easily charge near 100 dollars an hour, although it is often covered by health insurance. Giving half the population a personal trainer doesn't work nor scale. My method can help people who do not want to spend this money or have anxiety problems with seeking help. And do it for a fraction of the cost.
One a more personal note: The inspiration for DadBot comes from my own experiences trying to lose weight after becoming a dad. I found it hard to change my routine, especially with a full-time job, all the dad things and just trying to keep up with the general crazy world. I figured I could benefit from some kind of fitness coach, but quickly found that these tend to operate mostly during business hours. Which is exactly when I’d be working myself, ironically.
Asking around in my extended friend circle this was a common theme. We’re finding it hard to work out and keep in shape. For some of us it’s gaining weight, other it’s losing it. A lot of us find we can often only get a workout in when the kids are asleep or away.
At the moment I’m using DadBot for myself, as a form of “eat your own dog food”. DadBot currently sends me personalized messages and has been surprisingly spot-on.
How I built this
I already had the idea in my head but translating to code was hard, even with AI. My first goal was to define the features I wanted for the app, and I spent a couple of hours whiteboarding what I wanted and translated that into an architecture diagram. The key features I had in mind:
- AWS Lambda for serverless compute, because this application does not need to run permanently
- At least one Lambda to be behind the API Gateway to handle authentication
- And another Lambda for agent tools and chats
- And a lambda to (cheaply) host some simple regression machine learning models. Wait, we’re combining AI with old school ML? YES! More on that later.
- API Gateway to provide an API I can talk to
- Bedrock or Bedrock AgentCore for my agentic AI calls
- DynamoDB , a NoSQL database, for logging
- Amazon Amazon Simple Notification Service (SNS) to have e-mail, text message functionality, but also to connect to third-party apps and discord.
- For interacting with apps I figured I could self-host something like n8n , or simply use a service to reduce technical complexity. There are multiple offerings in this space.
- Eventbridge Scheduler to send reminders and check-in with the user during the day
- AWS Secret Manager to store API keys and tokens
- Terraform for AWS for infra as code. I’m an engineer myself, so I figured I could capture the entire application in some kind of Infra as Code approach (IaC) which makes it easy to re-deploy and recover the application. For this I opted to use Terraform , as I want to keep the option open to deploy additional services that may offer providers to interact with infra.
- Cloudwatch logging for metrics and system performance.
- Cloudwatch dashboards on top of that
- Python for almost all backend code. Coupled with small scripts to set up accounts and uv as a package manager for python.
Since using Kiro is a required part for the competition I figured I could convert my ideas into bite-size user stories and prompt away. I was surprised that when I presented Kiro with my idea and extra context it generated about 25 user requirements which already aligned pretty well. Throughout the project, I used the Deploy Infrastructure with Terraform Kiro Power .
It was definitely nice having a pocket Product Owner and some back-and-forth yielded almost the same features I had in mind. Kiro made it pretty easy to move from Requirements (user stories and definitions) -> Design (architecture and data models) -> Tasks (actual bite-sized units of coding work). Kiro came up with this design as part of the 1100-line design document:
An overview of an architecture diagram that Kiro came up with
I then used it to generate the code for the application, starting with infra and tests so I could check if the functionality seemed all right. I was actually pretty skeptical throughout, and probably burned more tokens (credits) than needed going back and forth giving instructions on minor refactors. There were some small errors that I found, such as circular dependencies in the infra code, minor hallucinations in python code (e.g. arguments that were not supported by the particular framework used in that particular version) and that it sometimes generated commands that did not correspond to the operating system I used.
The first version that I could actually deploy actually only took about 110 kiro credits and about 3 hours. Going beyond that and making something that I felt comfortable with deploying took two weeks and I had burnt 913 credits by then. I reviewed most of the code, but the initial version still came up to 45.000 lines of python and terraform code. There was a lot of debugging needed as the system became more complex, particularly for the AI infra part. I found it easier to use AI to get a working version of the code then take a step back and refactor to find a more optimal solution.
The choice to capture everything in Infra as Code did pay off, as deploying the entire application is ridiculously smooth when validating the deployment with
terraform validate and terraform plan:
Terraform planning stage shows we are about to deploy 161 pieces of infra.
before deploying it with
terraform apply (bonus: I can set-up a least amount of priviliges role to deploy instead of root credentials):
Terraform apply is done and the entire application is now deployed on AWS.
Which only needs 1 minute and 40 seconds to deploy the entire backend of the serverless application! Wait, 161 pieces of infra? What kind of architecture are we talking about?
Dadbot's Architecture Diagram
That’s a lot of infra, and most stem from trying to support multiple chat channels and working with multiple APIs that need to be integrated. Integrating proved to be a challenge as it adds tremendously to complexity. I found it easier to generate small test scripts and Jupyter (interactive python) notebooks to test functions. AI coding agents have no problem with saying something works to your face while it fails over and over. With the current state of the art models you still need to be on top of things, though it is becoming much more doable.
There are some design decisions I want to highlight:
- The Agent has tools: I added tools that the health coach can use, including
- weather (to help suggest activities),
- log food,
- log activities
- log progress,
- calorie estimation,
- manage activity preferences
- get activity history
- get calendar
- get profile
- predict weight loss (machine learning model, see below)
- More powerful AI to support the tools: I found out that some of the models I tried had trouble picking the right tool. So I eventually switched to Claude Haiku 4.5. This is a more expensive model, but more powerful.
- Hosting a machine learning model on AWS Lambda: I opted to host a simple regression model inside an AWS Lambda to calculate how calorie intake will translate to gains or losses. I probably would have preferred SageMaker because of more tooling around it to support the machine learning model lifecycle, but hosting it inside a Lambda works and is significantly cheaper.
- Fall-back method for the cold start problem with new users: People are unique and so are their metabolisms. I want to have a personalized model for every user (which can be a really lightweight model of a few kilobytes). Unfortunately, these kind of models preferably do need just a bit of data, which we do not have at the start (when we have a new user). In order to deal with that I simply have a fallback method that assumes that 7700 calories convert to 1 kg of body weight.
- I cache as much as possible: For the weather service I use OpenWeatherMap , which is limited in how many calls per day I can do. I retrieve the weather data once, and serve it from the DynamoDB cache throughout the day if a tool requests it.
- One-way via SNS and Two-way conversations that run via the API GW. I made the decision to only support a chat methode for two-way communication. The other channels are implemented one-way (for now, anyway). E-mail is possibly but I really don’t see any advantages in writing an email to my LLM when the goal is to remove hurdles. Text is easy to implement, but as I already had a few apps I use daily it seemed a bit redundant.. I settled on discord for the main method of communication (at least in this phase) because there are few limits. The API Gateway I use is invoked by a third-party service which delivers messages from chat apps.
- To not go live with users and not open to the public: I’m located in the EU, specifically the Netherlands. There are pervasive data protection requirements for me to adhere to, such as a “register of processing ” and a end-user agreement with transparency on how data is used. Additionally, I’d fall under the High-Risk category in the EU AI Act which means I have to be somewhat strategic. I likely would have to register a business too. Maybe I can do that in the future but I had to make the choice to keep the app private (for now).
- Ready for production: Even though I am not releasing the project now, I did set it up with separate dev/stage/prod environments through the infrastructure as code approach. I can easily “pack it up” and deploy it to another AWS account too.
- To not rely on LLMs for accurate results in calorie prediction: Yes, you can send a LLM a picture of pretty much anything and it can tell you in extreme detail what it makes out of it. However, asking it to estimate calories from an image tends to yield results that are just way off. To illustrate that: In a controlled test of five different food items (taken from a food website that had images of food as well as calories) I found that the estimates were generally about 60% off, even though the LLM was doing a good job of determining what is in the image. The way I want to tackle this problem is by using the agent to describe the food, then looking it up in the database (potentially using some kind of Retrieval Augemented Generation ). This way, I hope to provide more accurate calorie estimations.
Demo
At the moment I have most of my core features live. DadBot checks in several times a day and provides customized (and highly motivational) messages to the user.
Dadbot checks in and generates a highly tailored message showing it looked up the weather, the user's preferences, and the user's schedule for the day.
And during the evening (push message on discord)
DadBot checks in during the evening.
When asked, DadBot offers recommendations for a workout:
DadBot recommends activities based on past activities
And will hawk a user until there's enough information to generate a profile with 🦾
If the user's preferences are unclear (not set, in the case of a new user) DadBot asks for it and will log them.
And connects to Strava:
DadBot finds activities that the user logged on Strava (a popular fitness app) and gives feedback.
Web app
Whats the point of creating an amazing backend if you don't have your own app for it? So true, that's why I made a small web app for DadBot.
DadBot web interface
DadBot's landing page
The web app is coded in Next.js and Typescript. The web app allows the user to log in and check their weekly stats:
DadBot Dashboard
..features an activity streak counter (under goals):
Activity Streak
..and a profile management panel (and a light/dark mode switch as you can tell).
DadBot Profile management
.. as well as easy ways to connect Strava/Discord - and even change DadBot's name (if you'd like to)
I added it because while the AI agent works fine as a way of managing the profile, I found I often just want to verify it’s correct without making a trip to DynamoDB.
The app also includes the option to chat with DadBot and uses the existing API GW lambdas made for discord/twilio.
Note that in the screenshot below the user asks DadBot to use the strava and weather lookup calls. DadBot of course, is more than happy to help!
DadBot Chat in the web app
What is the stack I am using?
| Service | Resource Count | Purpose | Notes |
|---|---|---|---|
| Amazon bedrock | 1 Agent | AI fitness coach with Claude Haiku 4.5 | 2 action groups, 12+ tools |
| AWS Lambda | 10+ Lambdas | Serverless compute for all backend logic | Python 3.11, 128-512 MB |
| AWS DynamoDB | 8 Tables | NoSQL database for all data storage | On-demand |
| API Gateway | 1 REST API | HTTP endpoints for client access | Regional, 7 Resources |
| EventBridge | 3 Rules | Scheduled check-ins (breakfast, lunch, evening) | Cron-schedule like orchestration |
| SNS | 1 Topic | Multi-channel notifications | Some lambdas are subscribed to this |
| Secrets Manager | 3 Secrets | Secure credential storage | API Keys/Tokens |
| CloudWatch Logs | 10 log groups | Application logs | Monitoring and logging |
| IAM | 12 roles+policies | Access Control and permissions | Least privilege principle |
Web App Technology Stack
Currently I just run this locally, and it uses the backend I made before.
- Next.js 14 - React framework with App Router
- TypeScript - Type-safe development
- Tailwind CSS - Modern styling with typography plugin
- React Markdown - Markdown rendering in chat
- Recharts - Data visualization
- Lucide React - Icon library
Cost estimate
- AWS Lambda: Within free tier
- AWS Bedrock (Agentic AI): $1.56/month
- AWS Secrets Manager: $1.21/month (3 secrets stored)
- DynamoDB: Within Free tier
- API Gateway: Within free tier
- Cloudwatch: 2 cents
- Eventbridge: Within free tier
- SNS: Within free tier
Total cost with free tier: $2.79/month. That's 9 cents a day! Taking into account I am mainly spending money on Bedrock, the cost per user is about 5 cents per day because the costs for secrets manager are flat.
According to my calculations, without free tier I'd spend about $3.86 a month. That's still insanely cheap!
Additional Web App Costs
Hosting the app adds approximately 1.40 dollars. I run it locally (for now) to save costs and reduce my security footprint.
However, if I was to deploy it on S3+ cloudfront I'd increase my spend with:
- S3 Storage: typically <$0.10 for static site
- CloudFront: $0.085/GB data transfer (~$0.85/month for 10GB)
- CloudFront Requests: $0.0075 per 10,000 requests (~$0.19/month for 250k views)
- SSL Certificate: Free (AWS Certificate Manager)
- Total: ~$1.40/month assuming light/moderate traffic
(plus whatever I want to pay for the domain registration but I feel that’s a bit out of scope!)
What I learned
API Gateway makes rolling out APIs pretty easy: Some of the gaps I had in my knowledge were things that I could dive into with this project. Take API Gateway and routing: I remember spending hours on this a few years back and never really understand it. Diving into it with this project improved my knowledge and made me realize it’s actually much easier than I expected.
Adding tool calls to an agent and using AI to code on large scopes: I learned a ton more about using agentic coding tools at this scale. I’m coding with AI already in my job, but my approach is much more like a precision knife. I have some professional anxiety when doing large-scale refactors with AI. When I’m coding I tend to make small changes with and verify. With Kiro, my scope was the entire project. I did larger changes and asked Kiro to make bigger rewrites than I’d do when I was handling production code at work.
Integrating external APIs is hard: originally I had planned to integrate many more APIs and apps. I had to scale down my ambitions because there was no way I could cover all the integrations in the time I had
It’s actually quite cheap: I have barely used my AWS Free tier credits since it’s mostly serverless and I can remove the infrastructure whenever I am not working on the project or don't need DadBot. When it’s running, I estimate the daily cost to be about 5-9 cents per user per day, with most of my usage being free. My costs scale linearly with users.
AI generated code is bigger, and poses a challenge to review and maintain: A part of that is that LLMs do produce code that is very different from what human developers make. The code base is much larger than a similar system I could have coded “by hand” and I noticed that, without good steering, Kiro would go a bit off the rails and implement structured code that was undermining the approach it had just a short while ago.
One of the legends in the field of Software Engineering said that one of the greatest properties of code is how maintainable it is. Making sure that LLM-generated code is maintainable requires a lot of back-and forth with a lot of time spent on reviewing. I do believe it can be done, and that’s where being able to approach it from the software engineering angle is a useful skill to have in the age of AI.
Future work
These are the things I want to focus on next if I were to make this a proper product.
- Figuring out what I need to have in place to comply with local data protection laws since I’m storing highly personal health data!
- Launching the project proper for more users than myself and not going bankrupt on LLM calls
- More personalized dashboards for data-savvy users
- Since LLMs do actually do a decent job of classifying what is in the image, I want to collaborate with resources like the Dutch Levensmiddelendatabank , a data base of 150.000 food items that are being sold or made in the Netherlands. The UK has a similar database (CoFID ) and the US has the USDA FoodData . I believe only the latter permits commercial use. This will greatly improve the calorie prediction methods.
- Cold starts are a problem, and with Discord I have to acknowledge a message in 3s so I cannot always respond fast enough. The way I deal with that now is acknowledging the message right away, returning a ''
Thinking.." and editing the message when Bedrock has responded. The way I accept the discord messages from the user right now is using slash commands (e.g./chat hey Dadbot, can you give me a workout suggestion) but I feel that using slash commands kills the natural conversation flow. I hope to improve this soon.
In Closing
Thank you for reading my long-length article. If you liked it drop me a like (thumbs-up) and if you have any questions feel free to leave me a comment!
Despite me using AI for much of the project, the text and this post and all the drawings (aside from the header and indirectly from the Kiro interface screenshots) were created by hand and not Generative AI. I used Excalidraw to draw the architecture diagram.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article