Three Days to Production: My First Spring Boot CRUD Microservice
After reflecting on my reasons for choosing Java in my previous post, I wanted to see how it would feel to actually build something new with it—while also exploring a little deeper how AI tools could fit into my workflow. Before diving into my full-fledged engineering project (see my post on Building a Meaningful Engineering Project), I decided to run a little experiment—a spike, if you will. I wanted to see if I could build a small, production-grade service with Spring Boot, and more importantly, figure out how to make AI a real part of my learn-while-develop process.
The Experiment: A Real Service, Not a Toy
This wasn’t about building the next big thing. It was about testing the waters: could I move beyond “toy projects” and actually create something that felt real, even if it was just a first step? Most importantly, could I use this as a way to learn deeply while building, not just to get something working?
I set myself a challenge: build a small service with all the trimmings—layered architecture, real tests, CI/CD, Docker, the works. And do it with AI as my coding partner, but not my autopilot.
Learning by Building, Not Just Coding
The process was fast—not just the coding, but the research, documentation, and everything that went into building the project and this post. Copilot and other tools were great at generating code and suggesting patterns, but I made a point to pause, research, and review every suggestion. Sometimes the AI was spot-on; other times, it needed a nudge (or a total rewrite). The real value came from those moments where I had to apply my own engineering judgment—and that’s where the learning stuck.
This is where my approach diverges from what’s being called “vibe coding” or prompt-driven development. I’m not knocking it—those techniques absolutely have their place in spiking, prototyping, and exploring ideas quickly. But for professional development of real products, you need more than speed. You need understanding, maintainability, and the ability to make informed trade-offs. Blindly accepting AI-generated code without understanding its implications is a recipe for technical debt and brittle systems. The goal isn’t just to get something working; it’s to build something you can evolve, debug, and stand behind.
Why Deliberate Coding Matters in the Real World
Vibe coding—that is, letting the AI or your own momentum drive the next line of code without much reflection—can be exhilarating, especially when you’re exploring or hacking together a proof of concept. But in the context of real, professional software development, this approach quickly shows its limits. Production systems demand clarity, traceability, and a deep understanding of why things are built a certain way. My approach is about slowing down at the right moments: questioning assumptions, validating AI suggestions, and making sure every architectural or design decision is intentional. This isn’t about resisting progress or being overly cautious—it’s about building software that can be maintained, extended, and trusted by others (and by myself, months or years down the line). In the end, the discipline to pause, reflect, and own every line of code is what separates a quick win from a lasting contribution.
Every step was a chance to learn something new, not just to tick off a requirement. What surprised me most was how much ownership I felt over the project. Even though the AI was there to help, every decision—from project structure to error handling—was mine. The satisfaction came from knowing I was building something real, not just following a script.
Three Days, Real Results
In just three days and 30+ commits, I had a working CRUD microservice with all the essentials: tests, documentation, CI/CD, and a clean, maintainable codebase. This was all the more satisfying because, before this project, I had little to no real experience with modern Java or Spring Boot—I was learning as I built.
To get started, I followed a basic example from a YouTube tutorial to grasp the fundamentals of Spring Boot. But I didn’t stop there. I took that simple foundation and extended it far beyond the basics—adding proper unit and integration tests, writing documentation, making the service deployment-ready, improving the architecture (for example, by extracting policies and clarifying responsibilities), adding simple logging to key operations, and even enhancing the developer experience with tools like a Makefile. The end result is a project that goes well past the scope of any tutorial, shaped by real engineering practices and a focus on maintainability.
It wasn’t perfect, but it was real—and it gave me the confidence to tackle bigger things. If you’re curious, you can check out the result here: github.com/jerosanchez/pms-patient-service.