My application worked.
The API responded.
The frontend could call it.
The main flow did what I expected.
On my machine, at least.
Then I tried to move it outside localhost.
That was when I started finding things I hadn't really designed.
I had only assumed them.
Localhost is a very forgiving place
When I was building the MVP, a lot of things were simply there.
My Java environment was already configured.
The right processes were running.
I knew which port the application was using.
When something failed, I could open IntelliJ, restart a process, change a property, and try again.
None of that felt unusual.
It was just my development environment.
The problem was that some of those conditions had quietly become part of the application.
I just hadn't written them down.
For example, during development I had already run into things like:
Spring Boot trying to use a port that was already occupied
Ollama already running on localhost:11434 while I tried to start it again
Docker becoming necessary once I wanted the application to run somewhere other than my own setup
WSL turning what looked like a massive Git change into a CRLF/LF problem
configuration that made perfect sense locally but needed another look before deployment
None of these were particularly dramatic problems.
But together, they showed me something useful.
A working development environment can hide a lot of assumptions.
The question changed
While I was building the MVP, my main question was:
Does this feature work?
After I started preparing it for deployment, the question became:
What needs to be true for this feature to work?
That second question turned out to be much more interesting.
A feature might work because:
a process is already running on my machine
a particular port happens to be available
a local path exists
a dependency is reachable through localhost
an environment variable is already configured
my machine has something installed that the server does not
The code can be correct while the application still isn't ready to leave the machine it was written on.
That distinction seems obvious once you see it.
I don't think I really understood it until I tried to ship something myself.
One small example: localhost
localhost is convenient because it feels almost invisible during development.
If my Spring Boot application needs another service running locally, calling something like this feels completely reasonable:
On my computer, it is.
But the meaning of localhost changes the moment the application moves to another environment.
It no longer means:
my computer, where I already installed everything
It means:
this machine or container
And the service I expected may not exist there at all.
That forced me to stop treating addresses and ports as incidental details.
They were part of the deployment design.
Docker wasn't the goal
I didn't start the project because I wanted to learn Docker.
Docker appeared because I wanted somebody other than me to be able to run the application.
That difference mattered to me.
Learning a tool in isolation often feels abstract.
But once I had a real application in front of me, the questions became concrete:
What exactly needs to be inside this environment?
What should stay outside it?
Which port should the application expose?
What configuration should come from the environment?
What does the application expect to already exist?
Can I reproduce the same startup somewhere else?
Suddenly Docker wasn't a topic.
It was an answer to a problem I actually had.
What I check now before saying “it works”
I still build the feature first.
But before I consider it finished, I now try to ask a few more questions.
- What does this application assume is already running?
A database?
A local AI server?
Another API?
Something I started manually an hour ago and forgot about?
This question alone catches more than I expected.
- Is anything tied to localhost?
Sometimes it should be.
Sometimes it is just there because development started locally.
I want to know which one it is.
- Are ports part of the configuration or just part of my memory?
I had a Spring Boot application hit an 8080 port conflict and ended up running it on 8081.
It was a small issue.
But it reminded me that configuration I keep in my head is still configuration.
- Could I start this from a clean environment?
This is one of the questions Docker made much harder to avoid.
If the application only works because my machine has accumulated the right tools, files, processes, and settings over time, I want to know.
- If it fails, will I know why?
Logs, startup errors, health checks, and clear configuration are not exciting when the application is working.
They become very exciting when it isn't.
Deployment started acting like a test
I used to think of deployment mostly as the final step.
Build the application.
Finish the features.
Then put it on a server.
I'm starting to see it differently.
Deployment is also a test of how well I understand what I built.
It asks questions that localhost often doesn't.
What is required?
What is accidental?
What is configuration?
What did I assume would always be there?
What only works because this is my computer?
That's why some of the most useful things I learned from this MVP didn't come from adding another feature.
They came from trying to move the same feature somewhere else.
I'm keeping track of the small failures too
I've been documenting this project while rebuilding my development habits.
Not just the architecture or the successful parts.
The smaller problems too:
port conflicts
Git line-ending issues
Docker setup
deployment configuration
local AI dependencies
the gap between an MVP that runs and one that can actually be used
Most of these problems aren't impressive on their own.
But they are exactly the things I end up searching for when I'm building something.
So I'm writing them down.
Mostly because I know I'll need them again.
And maybe another developer will find one of them before spending an hour wondering why something that worked perfectly on localhost suddenly doesn't.
Top comments (0)