I Built a Personal “AI Coach” with No-Code × AI API — The Limits and Potential of Free Tools [Technovate Thinking ⑨ Day5 Part1]

This is Part 9 of my 12-part series documenting what I learned in the “Technovate Thinking” course at business school.

The pre-work for Session 5 was “implement an application that’s useful for your business or daily life, using whatever tools you choose.” This was the session where we put hands on keyboards and experienced the world of no-code tools that we’d studied the previous time. Honestly, when I was told “build an app,” my first reaction wasn’t anxiety — it was excitement. As someone who’s spent years in IT infrastructure, I felt like this was my chance to “solve my own problem myself.”

The Pain Point: Not Making the Most of My Daily Body Composition Data

When I thought about what to build, the first thing that came to mind was my morning routine.

I use a Tanita body composition scale every morning. Weight, body fat percentage, muscle mass, visceral fat level — the data syncs to my phone automatically via Bluetooth. I’ve been measuring without fail every day for years now. But I had no system for actually “using” this data.

I wanted to visualize trends with graphs. But most commercial apps with decent graphing features are paid. Was it worth a monthly subscription? That felt like a stretch. Besides, commercial fitness apps are too generic for my specific context — I want to increase muscle mass to improve my golf performance. I didn’t need “lose weight” or “restrict calories.” I needed answers to questions like “how do I reduce body fat while maintaining muscle mass?” and “what should I eat tomorrow?” — personalized advice tailored to my goals.

I could send screenshots of my body composition data to ChatGPT and get advice. I’d actually done that several times. But it couldn’t handle graphing or continuous tracking. Taking a screenshot every morning and pasting it into ChatGPT… that kind of manual process doesn’t last. The data was being collected daily, but I had no “system” to leverage it. That frustration became the theme of this app development project.

What I Built: My AI Coach – Eat & Training

What I built was “My AI Coach – Eat & Training” — a personalized AI coaching app. The concept was simple: “A system where I just input data each morning and AI automatically creates a meal and exercise plan tailored specifically to me” — built entirely with free tools.

Three core features:

  • Daily data input → automatic AI advice generation: Just enter daily body composition data (weight, body fat percentage, muscle mass, visceral fat level) and the AI auto-generates meal recommendations and exercise plans aligned with my goals
  • 3-day comparison analysis: Based on recent data trends, the AI provides specific change analysis like “your muscle mass dropped 0.2kg from yesterday — consider increasing your protein intake”
  • Graphs for weight, body fat percentage, and muscle mass: Visual trend tracking instead of staring at rows of numbers

I can hear the question: “Can’t you just ask ChatGPT?” The key is “systematization.” Just enter data each morning and optimal advice appears without any extra thought. Creating this state of “zero cognitive cost” is what I believed would be the key to sustainability.

Architecture: Stitching Together Four Free Tools

Every tool I used ran within free tiers. Four tools each played a distinct role, forming a pipeline.

AppSheet: The Mobile UI Layer

A no-code app development platform from Google. I built the form for entering body composition data on my phone, along with screens for viewing past data and AI advice. By simply specifying a Google Sheet as the data source, a CRUD app is auto-generated. UI customization is intuitive — just drag and drop. “Data entry from the phone, development from the browser” — this natural division of labor is AppSheet’s strength.

Google Sheet: The Data Hub

The central database where all data converges. Storing body composition data, housing AI responses, sourcing data for graphs — Google Sheet handles it all. The sheet structure: columns for date, weight, body fat percentage, muscle mass, visceral fat level, AI advice (text), and graph image URL.

Zapier: The Automation Engine

Zapier detects when a new row is added to Google Sheet and automatically calls the OpenAI API. It serves as the trigger that enables the “data entry → AI response” automation. Without Zapier, I’d need to manually hit the API each time — the system simply wouldn’t work.

OpenAI API (GPT-3.5-turbo): The Brain

Receives the body composition data and generates advice based on my goal (increasing muscle mass). Meal menu suggestions, exercise plan recommendations, commentary on data fluctuations — GPT-3.5-turbo handles all of it.

Here’s the data flow in summary: Enter data in AppSheet → saved to Google Sheet → Zapier fires as a trigger → sends a prompt to OpenAI API → writes the returned advice back to the Sheet → displayed in AppSheet. From the user’s perspective, this entire pipeline feels like “I entered data and advice appeared.”

I also experimented with a voice UI. Using VoiceFlow, the idea was “OK Google, what’s today’s advice?” and the AI Coach would respond. However, the VoiceFlow-to-Google Sheet integration didn’t work properly, so this remained unfinished. Still, confirming the possibility of extending to a voice interface was a worthwhile outcome in itself.

Hitting Walls: Wrestling with Free Tool Constraints

I got something that worked. But there’s a wide gap between “works” and “usable.” I kept running into free tool limitations, and figuring out workarounds each time consumed the bulk of my development effort.

AppSheet’s Wall: Graphs and Data Types

The biggest frustration was the charting limitation. AppSheet’s chart feature doesn’t support dual-axis graphs. I wanted to plot weight and body fat percentage on the same graph, but couldn’t. Only by displaying two metrics with different units and scales side by side can you spot insights like “weight dropped but so did muscle mass” — yet this visualization wasn’t possible.

As a workaround, I created the graph in Google Sheet, published it as an image with a public URL, and embedded it in AppSheet as an image. Not elegant, but functional.

Another subtle headache was the floating-point precision issue. I’d enter body fat percentage as “51.2” only to see “51.200000001” in the Sheet. Apparently, a floating-point conversion happens internally when AppSheet writes data to the Sheet. This wasn’t just a cosmetic issue — the inaccurate numbers were being passed to the AI in the prompt. I resolved it by converting to text type before saving, but I keenly felt that data type handling is the Achilles’ heel of no-code tools.

Zapier’s Wall: Real-Time Responsiveness and Model Constraints

On Zapier’s free plan, the trigger polling interval is 15 minutes. That means after entering data, it could take up to 15 minutes for the AI response to come back. During a busy morning, waiting 15 minutes is honestly a tough ask. There was a gap between the UX ideal of “instant advice” and the reality of the free tier.

Furthermore, loop processing (batch processing multiple data rows) is a paid-plan-only feature. The AI model selection is also limited to GPT-3.5-turbo — GPT-4 isn’t an option. The ceiling of “what you can do for free” became starkly visible.

OpenAI API’s Wall: Conversation History and Prompt Design

ChatGPT’s web version retains conversation context. But via API, each request is independent — no conversation history is maintained. There’s no concept of “continuing from yesterday’s advice.”

To work around this, I adopted the approach of including the past 3 days’ worth of data in every prompt. It increases token consumption, but it was the only way to preserve context.

And the biggest lesson was the critical importance of prompt design. My initial prompt was something like “Please give me advice based on body composition data.” What came back was “Eat a balanced diet” and “Get moderate exercise” — generic advice that could have come straight off a health clinic poster. That defeated the entire purpose of building a system.

After extensive trial and error, the prompt that finally produced useful results looked like this:

“Analyze the following 3 days of body composition data. The goal is increasing muscle mass. Cite specific numbers, identify changes from the previous day, and with the goal of muscle mass increase in mind, present tomorrow’s meal plan in 3 variations (Japanese, Western, convenience store options). Include an estimated protein amount for each menu.”

It took that level of specificity before the advice became genuinely “usable.” Prompt specificity decisively determines AI output quality — this is a truth that’s hard to grasp from casually using ChatGPT alone.

Data Input Automation: An Ambition Deferred

Ideally, I wanted to auto-capture data from the body composition scale’s app screen via OCR (optical character recognition). Manual entry every morning is tedious and carries a risk of input errors. I tried using scraping and OCR technology to automate it, but the body composition app’s screen layout was too complex for accurate automated recognition. This remains a future challenge.

On a side note, while developing, I once asked AI (Gemini) for guidance on tool configuration and received confident instructions referencing menu items that didn’t exist. AI hallucination is impossible to catch if you don’t have baseline knowledge yourself. Using AI effectively requires enough foundational knowledge to verify AI’s output — another lesson learned.

Seven Lessons Learned from Working Within Constraints

I’ve organized what I learned through this development into seven points. None of these are in textbooks — they’re insights gained only through getting my hands dirty.

  1. An AI agent is only worth building if it offers value beyond “just asking AI directly” — If ChatGPT gives an answer in 5 seconds but your system takes 15 minutes, you’ve gone backwards. If you’re going to systematize, you need value-adds that direct usage lacks: “automatic every day,” “just input data,” “with comparative analysis”
  2. A personal AI needs “context” to be truly personal — A general-purpose AI works for everyone but is optimal for no one. Personal goals (increasing muscle mass), lifestyle patterns (morning person), dietary preferences (Japanese food-centric) — only when this contextual information accumulates does it become “my” coach
  3. Handle data types with extreme care — Floating-point precision errors, date format mismatches, character encoding issues. Each is subtle, but left unaddressed they undermine data reliability and corrupt AI inputs. They’re insidious precisely because they’re invisible
  4. Systematization requires quantified and structured data — “I generally feel good” or “I think I’ve gained weight recently” can’t be fed into a system. Only when you measure numerically and store in a structured format does the foundation for automation exist
  5. AI dramatically reduces programming effort — Google Sheet function syntax, API call code, error handling implementation — tasks that are “findable but tedious” come back from AI instantly. Development speed felt at least 3x faster
  6. Free tools must be used with full awareness of their constraints — Free doesn’t mean bad. If you identify what you can and can’t do upfront and design within those limits, you can build something genuinely practical. But if you design to ideal specs without knowing the constraints, you’ll hit a dead end
  7. Prompt design decisively determines AI output quality — The gulf between “give me advice” and “cite specific numbers and present 3 meal plan variations” in terms of response quality is enormous. AI only does exactly what you tell it to do

“Decision-Making Under Constraints” Was Technovate Thinking All Along

Stepping back and looking at these seven lessons, I realized that they all converge on a single question: “How do you make decisions within constraints?”

AppSheet can’t do dual-axis graphs → work around it with Google Sheet image embedding. Zapier has a 15-minute delay → abandon real-time responsiveness and redesign the use case as “enter in the morning, check on the commute.” Only GPT-3.5 is available → compensate with prompt precision.

Every time I hit a constraint, I had to decide: “Would a paid plan solve this?” “Can I work around it by changing the architecture?” “Should I rethink the requirements altogether?” This continuous stream of decisions under constraints was, I now realize, the Technovate Thinking problem-solving process in its purest form.

Lesson: The Impact of “Solving Your Own Problem Yourself”

The assignment itself was open-ended: “Build some kind of app.” But the experience of combining tools to solve a pain point from my own daily life had a completely different feel from a hypothetical case study.

In case studies, you discuss “what should this company do?” That’s intellectually stimulating in its own way. But when you’re building a system that changes your own morning behavior, the way you prioritize requirements shifts. It’s no longer “nice to have” but “without this, I won’t keep using it” — the exercise sharpened my ability to identify what’s truly essential.

And one more thing: I experienced firsthand the value of “building something that works, even if it’s not perfect.” VoiceFlow was unfinished. OCR was abandoned. The graph was a workaround using image embedding. None of it was elegant. But entering data each morning and getting AI advice back — that end-to-end experience “worked.” Having an imperfect but functional system reveals what to improve next. Building something imperfect teaches you far more than striving for perfection and building nothing.

Next Up: AI in Business — Examining Expectations and Threats

The second assignment for Session 5 was to examine how AI is being used in my own business domain, what’s expected of it going forward, and what threats it poses. Drawing on the experience of actually building an AI app, I’ll write next time about discussing AI adoption from a broader perspective. When you’ve built something with your own hands, the “threats” you see are different.

Books Referenced in This Article

広告