Building My First Side Project: From Intuition to a Repeatable Way of Thinking
I’m a backend software engineer with over a decade of experience primarily in Java. I started this blog to share what I’ve learned in a simplified, approachable way — and to add value for fellow developers. Though I’m an introvert, I’ve chosen to put myself out there to encourage more women to explore and thrive in tech. I believe that by sharing what we know, we learn twice as much — that’s precisely why I’m here.
This is the first time I’m intentionally working on a side project end-to-end — outside of a company, outside of a team, and outside of an existing product system.
It’s just me, an idea, and the responsibility of turning it into something real.
At first, I assumed the challenge would be execution: writing code and building features quickly.
But I’ve realized something more subtle:
The hardest part is not building the feature — it’s deciding what to build, and how small that version needs to be to validate real user behavior.
This is just one of several challenges I’m starting to recognize, and I suspect there are more worth writing about as I keep building.
How I’ve Always Thought About Features
I’ve always approached features with a consistent mental model.
Whenever I work on something, I naturally think about:
why it exists and what value it creates
what problem it solves
how it can be simplified
what edge cases matter
what I explicitly don’t want to build
how it fits into the existing data model and UI
how the user experience should feel end-to-end
how to implement it with minimal user friction
what signals would indicate this feature is actually working
This isn’t something I learned recently — it’s just how I reason about problems.
Even in my engineering role, I’ve always used a strong user-story mindset: understanding intent, questioning value, and sometimes even challenging whether something should be built at all.
Over time, I realized this is what more senior thinking actually looks like:
Not just implementing features, but deeply understanding intent and improving it when needed.
The Problem I Didn’t Have a Name For
In my side project, I started running into a subtle issue.
I would do most of the feature thinking upfront — naturally and consistently — before writing any code: planning how it would fit into the existing data model, how it would behave in the UI, and what the user experience would feel like end-to-end.
But once I started implementing, that thinking had nowhere to live.
If I stored it in a Linear ticket, it would get buried in execution details. More importantly, a Linear ticket — as a small unit of work — often didn’t represent the full end-to-end feature vision, only the initial increment being implemented.
If I stored it in Google Docs, it would quickly become something I forgot to revisit.
So I was left with a gap:
A lot of clarity before coding… and very little preservation of that clarity afterward.
Seeing PRDs Differently
I’ve seen PRDs before — usually as input documents in product discussions or strategic meetings. But I never had to write them myself.
For context, a PRD (Product Requirements Document) is a structured document used to define what a product or feature should do, why it exists, and how success is measured before development begins.
They felt formal, structured, and somewhat distant from how I naturally think when building.
That changed in this side project.
Because I am now both the product thinker and the implementer, I started noticing that I may need a simple framework to structure this type of thinking, and a persistent place to store it so it could eventually be referenced when implementing features in Linear.
Not as something I fully have — but as something that might be useful to formalize.
PRD-Lite: A Repeatable Thinking System (Emerging Idea)
Over time, I noticed I was already doing a fairly repeatable type of thinking — just informally.
To make it easier to reason about, I started sketching a simple structure I might use for future features. I’m considering storing it as a Markdown file in the repo so it stays close to the code and could eventually be referenced during implementation.
I haven’t adopted this yet, but it feels like a direction worth exploring.
🧾 PRD-lite format
Why it exists Why this should be built and what value it creates
MVP scope What the smallest useful version includes
User flow What the user does
Data model (light) What objects exist
Out of scope What I am explicitly not building
Right now, this is more of a thinking scaffold than a system — something I use to avoid losing structure while I’m reasoning about a feature.
The AI Layer: A Possible Extension of This Idea
Another thing I’ve been thinking about is how this kind of structured thinking might interact with AI coding assistants.
If I eventually write these PRD-like notes in the repo, they could serve as useful context when working with tools like Claude or similar assistants.
Instead of re-explaining intent in prompts, the assistant could potentially use:
structured feature definitions
scope boundaries
user flows
data model assumptions
This is not something I’m actively doing yet — but it’s one of the reasons this idea feels interesting.
It suggests a workflow where thinking becomes more portable between planning and implementation.
Why This Matters in a Side Project
When you’re building alone, there is no separation between:
product thinking
decision making
implementation
Everything collapses into one continuous flow.
That makes it very easy to:
lose intent while coding
overbuild in the moment
forget original assumptions
drift away from the real problem you were solving
What I’m exploring here is not a process — it’s a way to preserve intent long enough to actually build from it.
Final Thought
I used to think PRDs were documents created for engineers to follow.
Now I see them differently.
They are not external instructions — they are a way to make your thinking persistent enough to actually build from it.
And for the first time building something on my own, I’ve realized I’ve naturally been doing product thinking all along — and I’m now starting to explore how to structure that thinking so it doesn’t get lost between idea and implementation.
Think clearly. Write it down. Build intentionally.
That’s the system I’m starting to discover
