TL;DR: I built and deployed a small website as an experiment. The key lesson was learning how to turn a vague idea into clear requirements, and then breaking features down into a simple, structured workflow.
Hi everyone. This is the first time I’m sharing some experience from when I deployed my own website independently.
Although my site has already been deployed online and officially registered, the features are still not complete, and it can only be accessed within China. So I cannot share a public link for you to visit yet.
Still, I can share my overall thinking, and I hope to learn and exchange ideas with more experienced builders.
Today’s topic is requirements analysis. When you have an idea, the most important step is turning that idea into concrete requirements. That’s not easy, which is why my first website was also an experimental project.
Starting from an idea: how can a startup or small team manage projects?
My first thought came from my interest in online note-taking and project management tools.
In my previous company, large teams often had their own project management systems. But those systems usually required filling in complicated forms and going through complex processes, which made them slow and inefficient.
Smaller companies often use tools like ZenTao, Jira, or Feishu. These tools are very general-purpose, but many features and workflows are unnecessary.
Some startups even rely on static documents or online documents to manage projects, but that approach is less automated and can easily become messy and hard to follow.
So I came up with the idea of building a simplified project management tool. This became the core feature of the website I designed. Only after having this idea could I start planning how to build the site.
Turning ideas into requirements: breaking down features
Turning an idea into requirements means breaking it down and refining it. There are many things to consider.
1) If other products are complicated, how can my system be simpler?
- Remove unnecessary features.
- Avoid complex configuration.
For example:
- In ZenTao, building product modules and splitting into many team groups might be unnecessary for small companies.
- In Jira, some configurations are very complex.
In many small companies, users might only care about:
- Who the users are
- What progress each person is making
2) How can the structure be clearer?
For progress reporting, project management can be structured as a simple model:
- Project → Requirement → Progress
A minimal workflow could be:
- Admins create projects.
- Project owners or requirement owners create requirements.
- Developers only need to report progress.
After defining the key requirements, you can then design the details, such as:
- Entity/data model
- API design
- UI flow
Considering feasibility and risks
To be honest, I did not do enough in this area. This was just a trial project, but I still made some considerations.
Feasibility
The target customers were small businesses and startups, and their budgets are likely limited.
So I did not invest heavily in technology or resources.
Since small companies typically have fewer users, the performance requirements are also lower, which means I can save a lot of costs.
Risks
Users might be concerned about security, but I have not thought too much about that yet.
Closing thoughts
In the past, I was purely a technical engineer. This is just a bit of my common sense and experience.
I’m looking forward to discussing with everyone, and I would love to hear your opinions and suggestions.
Top comments (2)
Really like how you broke the idea down into a simple workflow.
I’ve found that turning vague ideas into structured steps is often the hardest part of building anything — not the coding itself.
Curious: did your requirements change a lot once you started implementing?
Thanks a lot — you’re the first comment I’ve received.😊
And yes, sometimes it really does happen: once I start implementing, I realize that some ideas that look simple on paper aren’t simple at all. For example, I wanted developers to report progress on specific requirements. But then questions immediately come up: how do you break a requirement down into measurable progress? How should reporting permissions be defined? And how should overall requirement progress and project progress be calculated? All of that can get pretty overwhelming.
That said, since this is my first time building my own product, I’m treating these headaches as part of the process — iterating through them and improving as I go. As I gain more experience, I should be able to think through these issues earlier in the design phase, before implementation.
In my next post, I’ll also share more about what I learned during implementation and development.