Building Teddy Bud: A Student's Journey into AI, Agentic Development, and Product Building 🧸

How an idea turned into an actual application, the struggles behind it, and everything I learned along the way.

I've been wanting to write about how I built Teddy Bud for quite some time. Not just what the application does, but the actual journey behind it — the decisions, experiments, failures, debugging sessions, and all the little things that went into making it.

I'm currently a Class 12 student, preparing for JEE, and honestly, my daily schedule is quite busy. But I've always had a strong interest in development and product building. I enjoy imagining products, figuring out how they should work, and then finding ways to turn those ideas into something real.

Teddy Bud became one of those projects where I got to explore that passion properly.

Where it actually started

Before Teddy Bud, I had started working on another project called Pillow Bud. It was actually my first initiative towards building this kind of application. The original idea was to create an AI companion that could run its AI model locally on the user's device.

I initially developed Pillow Bud using Flutter and experimented with smaller Gemma and Llama models. I downloaded the models through Hugging Face and tried getting them to run locally.

At that point, I was still learning how to properly work with AI coding tools and manage application development. I encountered quite a few issues with the local-model approach, and Flutter also made it difficult to maintain the pace of development and quick iterations I wanted, especially with my limited free time.

Eventually, I had to put Pillow Bud on hold.

But I didn't want to abandon the idea itself. I wanted to understand how to plan an application properly, how to structure it, what makes a product maintainable, and how to make it genuinely useful for people.

So, I decided to revisit the idea and build it again with a more structured approach. That became Teddy Bud.

I spent time studying the requirements, thinking about the architecture, and understanding the different components that would be needed. I even started with a notebook and pen, sketching the application, its UI, the different screens, and how everything should connect.

I refined those ideas on paper before turning them into documentation and initial prompts for my agentic workflows.

I wanted to have a proper direction instead of simply giving an AI a prompt and hoping it would produce something usable.

Building with AI, but not blindly

One thing I really wanted to learn was how to use AI as an actual development partner.

I started exploring different AI tools, their capabilities, limitations, and how their usage could be optimized. I experimented with different workflows, remote development approaches, and ways of combining multiple tools.

Some of the tools that became particularly useful in my workflow were:

• Google Antigravity CLI
• ChatGPT / Codex IDE
• GitHub Copilot
• VS Code

I didn't restrict myself to using just one model or one agent.

I experimented with multiple agents working on different parts of the application, while I personally handled the orchestration. Sometimes, I would use multiple models at the same time, with one handling implementation and another reviewing the proposed changes or analyzing their impact.

I would compare their opinions, cross-check their suggestions, review the actual code changes, and understand what those changes meant for the rest of the application.

I didn't want to blindly accept generated code.

Even when an agent completed a task, I wanted to understand what it had changed, why it had changed it, and whether it could introduce problems elsewhere.

This approach taught me quite a lot about agentic orchestration, reviewing AI-generated code, managing iterations, and getting different models to complement each other.

I also spent time learning how to use GitHub properly, including Issues, Actions, repository workflows, and other development practices.

I came across concepts such as PEP guidelines, industry best practices, modular development, and proper project documentation. I gradually understood that building an application isn't just about making its features work. There is an entire engineering process behind delivering a reliable product.

The first working versions and the provider experiments

My initial development setup was a laptop at home.

For the early builds, I also created a web version. This was mainly for quick testing and iteration. It was much easier to experiment with the application and test different AI responses before moving deeper into the mobile application.

Initially, I connected the model using an NVIDIA API key.

It worked, although there was some noticeable latency. During my research, I also came across concerns about shared API-key usage and how increasing demand could affect response times.

I was reasonably comfortable with the initial setup, but the response quality and consistency weren't quite where I wanted them to be.

Then came one of the more frustrating parts of development.

When the application stopped responding

As development progressed, I started implementing more complex authentication workflows.

And that was where things became difficult.

The authentication system had multiple bugs. Fixing one issue sometimes introduced another, and the testing and debugging cycles started taking much longer than expected.

After spending quite some time fixing those issues, I encountered another problem: the AI model simply stopped responding in the application.

The web version was working relatively fine, which made the situation even more confusing.

I tried multiple iterations and debugging approaches, but the mobile application still wasn't behaving consistently.

Eventually, I compiled an APK to test the actual mobile experience.

That build took some time, and when I finally tested it, the model still wasn't responding properly. After several more iterations, I managed to get a response once, but subsequent messages would sometimes fail with connectivity errors or messages indicating that a response wasn't available.

It was genuinely frustrating.

I had already spent so much time developing the application, and now something that worked in the web environment wasn't reliably working on Android.

For a moment, it made me feel like giving up.

But quitting was never really an option in my mindset. I wanted to understand why it was breaking and find a proper solution rather than keep patching the same symptoms.

From NVIDIA to OpenRouter, and eventually Cloudflare

I started experimenting with different providers.

First, I moved from NVIDIA to OpenRouter. It was a reasonable improvement, and things were working better, but it still wasn't the completely reliable and flexible setup I was looking for.

I had already spent many hours testing different providers, comparing their responses, latency, quality, and overall behavior.

I encountered issues involving:

• Response latency.
• Inconsistent response quality.
• Connectivity and availability.
• Context loss during conversations.
• Different behavior across the web and Android environments.

Eventually, I moved towards Cloudflare.

Cloudflare offered a much more suitable setup for my current requirements, particularly with its available AI credits and daily credit refreshes.

Another important part of this decision was the Cloudflare Worker.

I wanted a proper gateway between the application and the AI providers instead of having provider communication scattered throughout the application.

The Worker helped me centralize that communication and gave me a much better place to manage requests, investigate failures, and identify where things were breaking.

It also made it easier to iterate on the backend without having to constantly restructure the entire application.

This was an important learning experience for me because I started understanding how backend infrastructure, API communication, and application-level debugging fit together.

I realized that choosing an AI provider isn't simply about finding a model that produces good answers. The entire experience depends on latency, reliability, context handling, connectivity, and how well the application communicates with the backend.

When I finally tried the Cloudflare integration, I could notice a difference. Teddy started responding much faster, and the response quality was better than what I had been getting with my earlier setups.

For now, Cloudflare has been the most suitable choice for what I'm trying to build.

Authentication: A surprisingly big learning experience

Authentication was another area where I learned quite a lot.

Initially, I considered implementing conventional account-based authentication, including Google sign-in.

But as I thought more about how Teddy Bud would actually be used, I started questioning whether that was necessary.

Teddy Bud is primarily a personal AI companion intended to be used on someone's own device, particularly their mobile phone.

It isn't the kind of application where users necessarily need to maintain an online identity and synchronize their account across multiple devices.

Implementing Google authentication also introduced additional complications and development overhead.

While trying to solve those problems, I realized that a simpler local-account approach would make much more sense.

That led me to explore local account storage, system-level credential security, secure storage mechanisms, and biometric authentication.

I started understanding how credentials can be handled securely using the device's own security facilities rather than treating authentication as just another login screen.

I also implemented biometric authentication to make accessing the application more convenient.

Of course, getting the entire workflow right wasn't easy. It failed multiple times during development and cost me quite a lot of time in testing and debugging.

But it taught me something important: authentication isn't just about checking a username and password. There are many connected parts, including credential storage, session handling, security, recovery, and the actual user experience.

Designing the experience: Brown, claymorphism, and Cozy UI

One of my favorite parts of building Teddy Bud was working on its visual identity.

I wanted the application to feel comfortable and welcoming.

Instead of using the usual generic AI application appearance, I explored different tones of brown and built a warm color palette around them.

I particularly liked how the different brown shades could blend into the environment without making the interface feel too heavy.

I also experimented with combining claymorphism and Material UI principles.

The idea was to bring together the softness and depth of claymorphism with the usability and consistency of Material UI.

I wanted the interface to feel cozy, familiar, and comfortable to spend time in.

After experimenting with different elements, colours, components, and interactions, I started calling this combination my own UI approach: Cozy UI.

Just to be clear, Cozy UI isn't an internationally established or officially recognized industry design standard. It's simply the name I gave to the UI/UX approach I created by combining these design ideas.

And after all those experiments...

Ta-da! Cozy UI was born. 🧸

I wanted this design language to exist throughout the application, not just on a few screens. I also wanted the website to carry the same identity.

Maintaining visual consistency between two different products was another interesting challenge.

It involved thinking about component consistency, spacing, typography, transitions, icons, and how the same design language could work across different screen sizes.

Why Teddy Bud?

The name itself also has a little thought behind it.

I wanted the teddy to become an identity throughout the application.

For many people, a teddy bear represents comfort, warmth, and a sense of emotional connection. It's one of those things that can make even the harshest minds melt a little and bring out a more lighthearted side.

I wanted that feeling to be reflected in the application.

The idea was to create something that could be more than just an AI interface — a buddy that listens, someone users can connect with and share their thoughts with.

I liked the idea of having a teddy as that companion. A teddy bear already carries a sense of familiarity and comfort for many of us, so having it as the identity of an AI buddy felt natural.

I also wanted users to be able to change the bot's name and make the companion feel more personal. Those identity changes would be reflected throughout the application.

That was the kind of experience I wanted Teddy Bud to offer: something that feels a little more personal, friendly, and lighthearted.

Building the Teddy Bud portfolio website

Another major part of this journey was developing a separate portfolio website for Teddy Bud.

Initially, I was particularly interested in how I could communicate the application's identity through a website.

I had several ideas involving motion graphics, interactive elements, particle effects, and different transitions.

What made me particularly proud was seeing how much my communication with the AI agents had improved.

I could describe an imagination or a motion design idea, explain how I wanted it to behave, and gradually turn that into actual elements on the website.

I could communicate the same visual identity as the application and make the website feel like an extension of the product rather than a completely unrelated landing page.

This experience helped me understand that product development also involves communicating ideas properly.

Knowing what you want is one thing. Being able to describe it clearly, translate it into requirements, review the implementation, and refine it until it matches your vision is another.

I also learned about several things that I hadn't initially considered, including reduced-motion accessibility, privacy policies, and other requirements involved in publishing and presenting a real product.

These might seem like small details, but they are important when you're trying to build something that people can actually use.

The point where it started feeling like a real product

There were several moments when Teddy Bud started feeling different from just another application I was experimenting with.

One of the biggest milestones was introducing the emotion distribution graph in the Discover tab. It gave the application another dimension beyond simply chatting with an AI companion.

Another important addition was data backup with passphrase protection and encryption. It made me think more seriously about protecting user data and building features that people could actually rely on.

These additions made Teddy Bud feel much more like a complete product rather than just an interface connected to an AI model.

And then came the Cloudflare integration, where I could finally experience noticeably faster responses and better response quality.

Seeing these different parts come together was a great feeling. It was one of those moments when I could look at the application and feel that the original idea was actually turning into something real.

Learning to balance development with everything else

One thing I haven't mentioned yet is that all of this happened while I was studying in Class 12.

I'm preparing for JEE, so naturally, I have quite a busy routine.

I couldn't spend entire days developing Teddy Bud, and I didn't want the project to become a distraction from my studies either.

Instead, I started making better use of the small amounts of free time I had.

Sometimes, it would be a short break after completing my programs in the school computer lab. Sometimes, it would be a little free time between other responsibilities.

I tried to utilize those small windows efficiently.

Even if I couldn't complete an entire feature, I could review an agent's changes, prepare documentation, investigate an issue, refine a prompt, or plan the next iteration.

Over time, these small sessions added up.

It also taught me that development doesn't always require sitting in front of a computer for eight hours straight. Sometimes, making consistent progress in smaller sessions is enough to move a project forward.

And honestly, the fact that I could continue working on something I was passionate about without completely losing focus on my studies made the journey even more meaningful.

More than just writing code

Looking back, Teddy Bud taught me much more than I initially expected.

I started with the idea of building an AI companion, but along the way, I found myself learning about:

• Authentication and secure credential handling.
• Backend architecture and API gateways.
• AI model integration and provider management.
• Agent connectivity and orchestration.
• Session handling and context management.
• Modular application development.
• UI consistency and design systems.
• GitHub Actions, Issues, and development workflows.
• Testing, debugging, and iterative development.
• Privacy, accessibility, and publishing requirements.
• Communicating technical requirements to AI agents.
• Reviewing and validating AI-generated implementations.

I also became more comfortable understanding how different tools and models could be combined to make development more productive.

I wouldn't say I know everything about these areas now. In fact, one of the best things about this project was realizing how much there still is to learn.

Learning to publish and share what I build

Once I started getting the application and its website into shape, I also began exploring what comes after development.

I started learning about publishing, distribution, presenting a project properly, and making it easier for other people to discover and understand what I've built.

During this process, I came across developer communities and platforms such as Dev.to and Hashnode.

I'm still learning how to share my work, write about the development process, and become part of these communities. I wouldn't say I've figured all of that out yet, but I want to improve at it.

I think building something is only one part of the journey. Learning how to present it, explain the decisions behind it, receive feedback, and connect with other people who are building things is another important part.

That's also one of the reasons I'm writing this article.

Where I am now

Teddy Bud is something I'm genuinely proud of, not because everything worked perfectly, but because of everything that happened while getting it to this stage.

There were working builds, broken builds, authentication failures, provider migrations, confusing Android bugs, and countless iterations.

There were also moments where an idea that existed only in my notebook finally became an actual feature.

I started with a laptop at home, an idea, and a willingness to experiment. Gradually, I learned how to plan a product, coordinate multiple AI agents, manage a development workflow, understand backend systems, and bring the application and its website together.

I'm still a student, still preparing for my exams, and still learning how to become a better developer and product builder.

But I think that's what makes this journey special to me.

I didn't wait until I knew everything about development to start building something. I learned many of those things because I actually started building.

And I'm looking forward to learning much more, improving Teddy Bud, and building many more products along the way.

Teddy Bud is not just an application I built. It's also one of the projects through which I discovered how much I enjoy turning ideas into actual products.

Thanks for reading! And if you're also a student experimenting with development or agentic AI, I'd genuinely love to hear about what you're building.