Updating my Calorie Tracker app using Opencode and SDD

Trying to learn a new skill can be hard, having a goal in mind helps me move forward though. Using AI to accelerate my development has me more motivated to create than I have been in a very long time. So... I am pushing forward to see if I can get my first mobile app ready to be released on the play store!

I think every Android developer knows that "just one more feature" feeling. Your app works, but under the hood, it can be a bit of a mess. In my case, API keys were scattered like hidden Easter eggs, and the app was juggling direct calls to services like Edamam and Gemini like a nervous waiter. One bad commit and my secrets would be public property.

I realised I needed a clean break, but I’ll be honest: I’m still very much in the middle of learning how to do this right. This is my first real attempt at splitting a project like this, and I’m definitely still in the "experimenting and failing" phase.

The Plan: A Handshake in Progress

The goal is to split the app in two: an Android frontend for the UI and a Go backend to handle the heavy lifting. Instead of diving straight into code for both, I tried writing the "contract" first—a simple Markdown file describing the endpoints and error codes.

It’s not a fancy industry standard; it’s just me trying to decide what the two sides should say to each other before I get lost in the syntax. To help bridge the gap, I'm using OpenCode to handle the development, using that spec to guide its implementation.

The Status: Backend First

I haven't actually touched the Android code yet, but the Go backend is starting to see some real progress. Here is what I'm learning while building the "server" side of the deal:

• Go is a friendly playground: It's been a long time since I did anything in Go, but its "no-nonsense" standard library makes it easier to experiment without getting buried in framework ceremony.
• The spec acts as a referee: Even though I'm building both sides, I found that I constantly forget what I decided ten minutes ago. Having that Markdown file keeps me from guessing while I build out the Go handlers.
• Fixing things in one place: I already hit a snag with how Edamam returns measurement data. Instead of worrying about how the Android UI will handle it later, I'm trying to fix it in the Go backend so the data comes out clean from the start.

The Lesson So Far
I’m definitely not an expert at systems architecture yet. Right now, the Android app is still "messy," but by documenting the "seam" between the two halves early on, I'm hoping I've given myself room to make mistakes on the backend without making the eventual frontend migration a nightmare.

I’m still tweaking the Go binary and seeing how far I can push things like rate-limiting, but for a first attempt at "separating concerns," it feels like a solid, humble start.

I am interested to hear from the community, how have you gone about mobile app development? Any pitfalls I should look out for?