Last time, we talked about how to clarify requirements and turn a vague idea into something concrete. That is the first step.
But as someone asked in the comments: “Ideas and execution are two different things. What if things change once you actually build it?”
That is true. In real execution, you will always spot logical gaps, or suddenly come up with a better idea. So requirement refinement is always work in progress.
1. From “minimal” to “richer”: how requirements become more complex
In the very first version, I only thought about the simplest model:
- Project → Requirements → Progress
I felt that was enough. If it runs, it is fine. But once I started coding, I realized it was far from enough.
Since this is my own knowledge base / management system, why not collect other scattered needs as well? For example:
- Link and document collection: where do useful references go?
- Bug list: should I step into the same pit again next time?
- Tech stack tracking: what versions does the project use? I need a “ledger”.
As a result, the final feature set became much larger than the initial draft.
2. Documentation: dealing with constant changes
Since requirements keep changing (which is normal for personal projects), documentation is necessary to avoid chaos.
At the moment, I use two main ways to record requirements: one high-level, one detailed.
2.1 Spreadsheet (a backlog, like a Notion requirement pool)
I keep a spreadsheet and put every requirement into a list. This lets me see, at a glance, how much work is still pending.
| Requirement | Priority | Status | Description |
|---|---|---|---|
| Link collection | High | To do | Collect and manage project-related reference links and documents |
| Bug tracking | High | To do | Record and track issues found during development |
| Project management | High | To do | Manage project basics, progress, and milestones |
| Tech stack management | Medium | To do | Record and maintain the technologies and versions used by the project |
Even for a personal project, I strongly recommend keeping the status up to date. Seeing “To do” become “Done” is one of the best sources of motivation.
2.2 Feature details (my “personal PRD”)
This is basically what product managers call a PRD. But since I am the product manager for myself, I do not need to make it overly formal.
I usually follow an outline like this. In practice, I merge requirement notes and development notes into one document to keep things simple:
- Background: Why do I want to build this? What problem does it solve?
- References: How do others do it? (Screenshots + feature notes.)
- Key points: What should the feature look like?
- Roles and permissions: Who can view and who can edit?
- Database entity design: This is development-oriented, but thinking about schema early saves a lot of detours later.
The biggest benefit of documentation is that it prevents forgetting and reduces mess.
For example, while designing the “project management” module, I suddenly realized a team lead permission needed adjustment. If I only keep it in my head, I will forget it in a few days. But if I record it as a change in the feature details, it stays clear when I implement it.
3. Tech stack choices: not the most expensive, but the most practical
Honestly, I am not an experienced architect. Since this is my first serious small project, my principles are simple:
- Use what I already know well
- Make it run first
3.1 Core framework
- Frontend + backend: Vue + Java (Spring Boot)
- Architecture: the project is small, so I am not chasing microservices or distributed systems. A simple monolith is enough, and deployment is easier.
3.2 The storage dilemma (middleware)
For file storage, I spent some time thinking about options:
- MinIO: self-hosted, data stays under my control. But I need to manage capacity and operations, and migration later can be painful.
- Cloud OSS: very convenient, but it costs money. Also, there are many stories about unexpected billing or account abuse, which feels risky.
My conclusion: tech choices are not permanent. For now I will stay flexible and decide based on the actual deployment environment.
3.3 Database
- MySQL: PostgreSQL is popular lately, and many people are switching. But for me, MySQL is the most familiar and the least risky.
- Persistence layer: I chose MyBatis-Plus for speed and convenience.
3.4 Embracing AI
Since this is a new project, I want to try something new. I have already integrated Spring AI and combined it with the GLM-4.5 model.
The early test results look promising. Next, I plan to build some AI-assisted features.
4. Final thoughts: why “reinvent the wheel”?
If I used an off-the-shelf backend framework (for example, RuoYi), development would probably be twice as fast.
But I do not want to do that.
I want my first project to be something I built entirely by myself. That includes basic but tedious parts like login, registration, and permission/authentication. I did not rely on a ready-made framework for those (although I did read a lot and tried to implement reasonable security protections).
For a beginner’s first project:
Your framework does not need to be advanced, complex, or even the newest.
As long as it supports shipping the product, lets you run through the whole process, and helps you learn, it is a good tech stack choice.
Top comments (0)