Reading Time: 10 minutes

NourishNot: From a Personal Problem to a Privacy-First Android Application

How I used AI-assisted development, software engineering principles, and product thinking to build an Android application focused on understanding hunger and cravings.

Project: NourishNot
Platform: Native Android application
Technology: Kotlin, PHP, REST APIs, MySQL
Role: Founder, Product Owner, Technical Lead
Development approach: AI-assisted, human-directed
Status: Private beta

Website: https://nourishnot.app

1. The Problem: Understanding Why We Eat

NourishNot started with an Excel spreadsheet.

I had been tracking my sleep and mood, looking for patterns in how I felt from one day to the next. I noticed that poor sleep often seemed to influence my mood, energy, and eating habits.

The spreadsheet worked as a basic record, but it had a fundamental problem: it wasn’t available when I needed it most.

By the time I sat down at my computer to record something, the moment had passed. I was trying to understand behaviour after the fact rather than capture the circumstances surrounding it.

That led me to a question:

Could I build a mobile application that helped someone understand what was happening before they reached for food, without turning the experience into another complicated tracking exercise?

Most food-tracking applications focus on what people eat: calories, carbohydrates, protein, portion sizes, and nutritional targets.

I wanted to explore a different question:

Why do I want to eat right now?

That became the foundation of NourishNot.

2. The Objective: Make Self-Reflection Simple

The intended experience was deliberately straightforward.

When someone feels the urge to eat, they open NourishNot and encounter a simple question:

Could you eat a plain apple right now?

The question, which I refer to as the Apple Test, is intended to create a brief pause between the urge and the decision to eat.

If an ordinary food sounds appealing, physical hunger may be involved. If someone only wants a particular snack, there may also be an emotional, habitual, or environmental influence.

It is not a medical test, and the answer is not a diagnosis.

The purpose is to encourage awareness.

From there, users can optionally record additional context, including their mood, sleep, activity, and circumstances surrounding the urge.

Over time, these observations can help reveal recurring patterns.

My Design Principles

I established several principles for the experience:

Minimal friction: The core interaction should take seconds, not minutes.
No judgment: Cravings are observations, not successes or failures.
Privacy by design: Users should not need to surrender identifying information to receive value.
Optional context: Additional tracking should provide insight without becoming mandatory.
Actionable awareness: The objective is to help people recognize patterns and make more informed choices.

One of the hardest product decisions was deciding what not to include.

Every additional question might improve the data, but it also increases the effort required to use the application.

An app designed to help someone pause during a craving cannot demand five minutes of data entry every time they open it.

3. Ownership: What I Personally Contributed

NourishNot was developed primarily through AI-assisted coding, often called vibe coding.

I did not manually write every line of Kotlin, PHP, or SQL. AI tools generated substantial portions of the implementation.

My role was to define what the application needed to accomplish, establish requirements and technical constraints, direct development, evaluate implementations, investigate problems, test behaviour, and decide when functionality was acceptable.

My previous experience in software engineering, enterprise applications, and technology leadership informed these decisions.

My responsibilities included:

Defining the product concept and user experience.
Translating user needs into application workflows and requirements.
Selecting the Android and backend architecture.
Establishing privacy and security expectations.
Directing implementation through AI coding tools.
Evaluating interface behaviour and refining workflows.
Testing builds and investigating defects.
Managing development priorities and feature scope.
Preparing the application for beta use and ongoing improvement.

The distinction matters.

AI can generate code quickly, but it cannot independently determine whether that code solves the correct problem, produces an appropriate user experience, or creates unacceptable security and maintenance risks.

Those decisions remained my responsibility.

4. Architecture: Keeping the Mobile Experience Separate From the Backend

NourishNot uses a native Android application written in Kotlin, supported by a PHP backend exposing REST APIs and using MySQL for server-side persistence.

I chose this approach to separate the mobile experience from the services required for selected online features.

At a high level, the architecture consists of three layers.

Android Client

The Kotlin application handles the user interface, core check-ins, local data management, and interaction with supported backend services.

A local-first design allows users to record and review personal information without requiring every interaction to depend on a server connection.

REST API Layer

The PHP backend provides controlled endpoints for features requiring server-side processing.

Rather than allowing the Android application to interact directly with the database or external AI services, those interactions are mediated through the backend.

This creates a place to enforce input validation, protect credentials, apply usage limits, and control which operations are permitted.

MySQL Database

MySQL supports the backend’s data persistence requirements.

The database is not directly exposed to the Android application. Requests pass through the API layer, where they can be validated and handled according to the application’s rules.

Why This Architecture?

The approach provided several practical benefits.

First, I could keep the mobile experience relatively independent from backend implementation details.

Second, server-side credentials and AI integration logic could remain outside the distributed Android application.

Third, backend changes could be developed without necessarily requiring a new Android release, provided the existing API contract remained compatible.

There were trade-offs.

Maintaining a mobile client and a backend creates additional responsibilities involving API compatibility, deployment, error handling, configuration, and ongoing security maintenance.

For a solo developer, those responsibilities are significant.

However, I considered that separation worthwhile for an application combining local personal tracking with optional online capabilities.

5. Technical Decisions and Trade-offs

Native Android Rather Than Cross-Platform

I chose to focus initially on Android using Kotlin.

This allowed development around one mobile operating system rather than splitting attention between Android and iOS.

The limitation is obvious: the application is not natively available on iOS.

For an early-stage product, I accepted that constraint rather than increasing scope before demonstrating sustained demand.

Privacy Without Mandatory Registration

Many applications begin by requiring users to register.

NourishNot does not require an account for basic use.

Instead, anonymous identifiers support application functionality without requiring users to provide names, email addresses, or passwords.

Optional Google-based history protection is available for users who want to reconnect their history across installations.

This approach reduces onboarding friction and unnecessary collection of identifying data.

It also introduces complexity. Anonymous use, local storage, optional history protection, and device migration require careful handling so that convenience does not compromise privacy.

Local-First Storage

Personal check-in information is stored locally by default.

The application uses encrypted storage for sensitive records, reducing exposure if application files are accessed without authorization.

Certain optional features require communication with backend services, so local-first does not mean that every operation is entirely offline.

The important architectural principle is to minimize unnecessary data transmission and keep users informed about optional online features.

Manual Data Entry Instead of Early Health Integration

Sleep and mood context can be recorded manually.

Integrating Android Health Connect could reduce user effort, but it would introduce additional permission handling, compatibility requirements, data interpretation, and testing.

I chose to prioritize the core experience before expanding into automatic health-data integrations.

This is an area where the trade-off remains open.

Manual input is easier to control technically but introduces friction. Automation may improve convenience, but only if it creates enough value to justify the additional complexity.

6. Security and Privacy: Designing for Trust

Because NourishNot deals with eating behaviour, mood, sleep, and potentially sensitive personal circumstances, I treated privacy and security as foundational requirements.

I was developing the application without a dedicated security team, which made the choice of understandable, maintainable safeguards especially important.

Protecting Data on the Device

Sensitive local records use AES-256-GCM authenticated encryption.

The application also minimizes unnecessary Android permissions. Location is optional and supports context-based insights rather than being a prerequisite for using NourishNot.

The broader goal is to avoid collecting or exposing information unless it serves a clear product purpose.

Protecting API Endpoints

The Android client communicates with the backend through APIs.

That creates an important trust boundary.

A request originating from a mobile application cannot automatically be assumed to be safe. Clients can be modified, requests can be replayed, and public endpoints can be called independently of the application.

The backend therefore incorporates input validation, expected event-type restrictions, prepared database statements, and rate limiting.

Rate limiting is particularly important for AI-related endpoints because abuse can create both service disruption and unexpected operational costs.

Managing Secrets

Server-side credentials and API keys are kept out of the publicly accessible web directory and are not embedded directly in the distributed application.

The intention is to separate configuration secrets from application code and reduce the risk of accidental disclosure.

AI Safety Boundaries

NourishNot’s AI Coach is designed to provide supportive reflection, not clinical diagnosis or treatment.

Its instructions include boundaries intended to prevent it from presenting itself as a medical or mental-health professional.

This is an important distinction because AI-generated advice can sound authoritative even when the model lacks sufficient context or expertise.

Prompt-level safeguards are useful, but they are not a substitute for testing and monitoring behaviour.

Security Is a Continuing Responsibility

These controls reduce specific risks; they do not make an application immune to attack.

One of my continuing responsibilities is to evaluate security as functionality evolves, particularly where new endpoints, external services, permissions, or data flows are introduced.

7. Engineering Challenges: Functionality Was Only Part of the Problem

The challenge was not simply getting an Android application to run.

It was creating an experience that remained useful, understandable, and manageable as additional capabilities were introduced.

Challenge 1: Balancing Data Collection With Usability

More contextual information can make behavioural patterns easier to interpret.

But every additional field creates friction.

I had to balance the desire for better insights against the risk of turning a quick reflection tool into a detailed journal.

The design response was to keep the initial question simple and allow additional context to remain optional.

The principle was straightforward: collect information because it creates value, not merely because the application is capable of collecting it.

Challenge 2: Introducing AI Without Turning It Into Medical Advice

Adding an AI Coach created opportunities for more personalized reflection.

It also introduced a new category of risk.

Users might disclose emotionally sensitive information or ask questions requiring clinical expertise.

The solution was to define a narrower purpose for the AI Coach: supportive reflection, awareness, and practical non-clinical guidance.

I introduced behavioural boundaries into the AI integration rather than treating a general-purpose chatbot as appropriate for every situation.

This remains an area requiring continued evaluation because language models can produce unexpected responses.

Challenge 3: Controlling Feature Expansion

AI-assisted development changes the economics of adding features.

Something that might once have required days of development can sometimes be generated much more quickly.

That creates a temptation to keep expanding the application.

But faster implementation does not automatically mean better product decisions.

I have had to continually return to the original purpose of NourishNot: helping people understand their cravings with as little friction as practical.

Features need to justify their contribution to that objective.

Otherwise, they add complexity without necessarily improving the experience.

8. Testing, Documentation, and Maintainability

One lesson from AI-assisted development is that code generation and software verification are different activities.

A successful build establishes that an application can be compiled. It does not prove that every workflow behaves correctly, that the application is secure, or that users understand the interface.

Functional Testing

During development, I have tested application workflows through private use and beta feedback.

Testing has focused on whether the intended interactions function as expected, including recording observations, reviewing history, navigating between features, and interacting with optional capabilities.

I have also used development iterations to investigate reported problems and refine the user experience.

Security-Oriented Review

Security considerations have included local data protection, API input validation, credential handling, rate limits, and avoiding unnecessary permissions.

These represent engineering controls that require continued verification as the codebase changes.

Documentation and Supportability

The application has a public help centre covering core workflows, tracking, privacy choices, history protection, and troubleshooting.

This documentation serves two purposes.

It helps users understand the product without needing direct assistance, and it makes application behaviour more explicit.

From my background in technical support leadership, I understand the operational cost of software that functions but is poorly documented.

A feature is not truly finished if nobody can understand how to use it, troubleshoot it, or maintain it.

Maintainability

Separating the Android client, API services, configuration, and database responsibilities provides a foundation for maintaining the application.

However, AI-assisted development can also introduce duplicated logic, inconsistent conventions, and unnecessary abstractions.

Those risks require ongoing review and refactoring.

My goal is not simply to keep adding functionality, but to maintain an implementation I can continue to understand and support.

9. Outcome: From Spreadsheet to Working Beta

NourishNot has progressed from a personal spreadsheet experiment into a working Android application being evaluated through a private beta.

The application now supports a broader set of experiences than the original concept, including hunger and craving check-ins, contextual tracking, historical patterns, and optional AI-assisted features.

It also has a supporting website, educational content, and user documentation.

The most important outcome so far is not the number of features implemented.

It is that a personal problem became a functioning product that other people can use and evaluate.

At this stage, I am treating the application as an evolving product rather than claiming that its long-term impact has been established.

I still need stronger evidence about sustained engagement, which insights users find most valuable, and whether the experience remains sufficiently simple over time.

10. What I Learned

AI Speeds Up Implementation, Not Judgment

AI-assisted coding made it practical for me to build across mobile development, backend APIs, database operations, and AI integration without assembling a conventional development team.

But the bottleneck shifted from writing code to making decisions.

I still needed to know what I wanted, identify defects, evaluate alternatives, challenge unnecessary complexity, and determine whether the result was acceptable.

Privacy Is an Architectural Decision

Privacy is much easier to address when it shapes the application from the beginning.

Choosing not to require accounts, separating local and server-side responsibilities, minimizing permissions, and protecting API credentials all influence the design of the system.

They cannot be added simply by publishing a privacy policy.

Documentation Is Part of the Product

Working in customer support and operations taught me that unclear systems generate avoidable support demand.

That experience influenced my decision to provide user guidance and troubleshooting documentation while NourishNot was still evolving.

The Original Problem Must Remain Visible

As capabilities expand, it becomes increasingly important to ask whether a feature helps solve the original problem.

The objective was never to create the largest possible wellness application.

It was to help people better understand the moments when they want to eat.

That remains the standard against which new functionality should be evaluated.

11. What I Would Improve Next

There are several areas I would prioritize as the application matures.

More systematic automated testing. Strengthen repeatable regression coverage for core Android workflows and backend API behaviour, particularly around invalid input, data integrity, and changes to existing features.

Better insight validation. Evaluate whether patterns presented to users are genuinely useful and understandable, rather than simply statistically interesting.

Improved observability. Continue refining how the application identifies and reports failures while avoiding the unnecessary collection of sensitive personal information.

Careful integration of external data. Revisit options such as Health Connect where automation meaningfully reduces effort without introducing excessive permissions or architectural complexity.

Continued security review. Reassess trust boundaries, backend protections, and AI safety behaviour as the feature set grows.

Scope discipline. Prioritize improvements that reduce friction or make insights more useful before introducing additional capabilities.

These improvements are not evidence that the current product has failed. They represent the work required to move from a functioning beta toward a more mature, maintainable application.

12. Closing Thoughts

NourishNot began because I wanted to understand a behaviour in my own life.

What started as a spreadsheet became an opportunity to apply product thinking, software engineering principles, security awareness, and AI-assisted development to a real problem.

The experience reinforced something I have learned throughout my career in software and customer operations:

Building functionality and delivering value are not the same thing.

A product can compile successfully, pass a series of checks, and still be confusing, unnecessarily complicated, or poorly aligned with the problem it was meant to solve.

The responsibility of the person directing development is to recognize that difference.

For NourishNot, my goal remains straightforward: build an application that helps people understand their patterns without judgment, unnecessary complexity, or avoidable compromises to their privacy.

Explore NourishNot: https://nourishnot.app