Ever thought about how to make a project to build a unicorn start-up? I can’t answer that, but I can tell you how to build a product to serve an audience. You just need to believe that the idea you have is something that addresses the drawbacks you identified, and the solution you can work on. If you truly believe in the idea, no matter how small it is, it will work and don’t worry if it already exists, but you want it with some other features, as there are to-do list apps backed by big tech giants, and many social media apps on your phone that all connect you with people — just in different ways. Even a small variation can add value to the ideation process. So, first have an idea.
Define the specifications
Divide into Version, Use VCS
Update builds daily
Use Bug Database
Fix bugs before writing new code
Have an Up-To-date Schedule
Program in a quiet, focused environment
Write Tests
Build a Team
Review Usability, UI and UX
Automate Build in one go
Define Specifications
There is a saying that “well begun is half done”, before writing the code, you need to know what you want clearly, writing it down will greatly help both you and your peers.
What to write down?
You must think about the user’s perspective, describe how a product will work, what features the user’s will be using. Write down the features, like screens, menus, dialogs and refine all your vivid ideas to describe them more clearly. Don’t go into how the code will be written, just talk about the user’s perspective of using your product.
Design: Attention to Detail
Design your product, go into every small detail, attention to small details is what makes a product different from a project. Describe every feature and every minute detail clearly, how the program will work. By doing so, you are forcing yourself to design the program.
Things to Keep in Mind
Writing Specs is a lengthy process, and due to our attention span of focus, you will lose track easily and frequently, so to stay on track, you must keep a few things in mind.
One author: Only one person should write the specs, even in your team, you are allowed to take suggestions, but only one person must work on specification, because specification is a way to give direction to everyone, not the final product, but on working multiple persons on this will cause quarrel and waste of time.
Scenarios: Writing specs means designing the product for users, and any product will be used by different user base. So, create personas, and based on those personas create features and design UI if applicable.
Nongoals: Mention what you want in the future but for now that feature is not necessary, so keep track of nongoals to avoid getting lost in the complex jungle of distractions.
Even More details: The more you write about the details, the more you’ll understand what to build and the vivid picture tends to be clear.
Keep Specification Alive: Update the specs, with changes in plan, nongoals, scenarios and continuously track your progress.
-
How to Write
- Rule 1: Be Funny
- Rule 2: Writing a spec is like writing code for a brain to execute.
- Rule 3: Write as simply as possible
- Rule 4: Review and reread several times
Divide into Versions and Use VCS
If you plan to build a solution for a large user base, you need to keep up with the fast-changing world. It doesn’t matter how well you’ve built your product — you must continuously update and improve its features. It’s a never-ending journey. You can’t include everything in the first prototype, and you’ll inevitably encounter bugs that can consume time and resources.
To stay organized and track your code, features, and versions, use a version control system. I personally use Git with GitHub — it makes collaboration and progress tracking much easier.
No matter how smart you are, you can’t create the final version in the first go. You’ll write code, and yes — it will throw errors. The same goes for features. You can’t expect to make everything perfect at once. That’s why it’s better to divide your work into versions. It’s completely okay to have fewer features or even open issues in your initial versions, rather than trying to build everything at once and take forever to deliver.
To stay organized and keep track of your code, features, and progress, use a version control system. I personally use Git with GitHub — it simplifies collaboration and helps you track what’s changing, and when. This is a simple workflow you can follow:
Choose a Version Control System
• Git is the industry standard—pair it with GitHub, GitLab, or Bitbucket. I personally use GitHub.Create a Main (Master) Branch
• This holds your current stable, released version. Treat it like “production only.”Spin Up Development Branches
• For each upcoming version or major feature set, branch off from main. Name them clearly (e.g., devV1.1, devV1.2).Work in Feature Branches
• Whenever you add a feature or fix a bug, make a feature branch from the relevant dev branch (e.g., feature/new-login, fix/bug-123).Merge Back into Development
• Once a feature is complete and tested, merge it into its parent dev branch.Release a New Version
• When the dev branch is rock-solid, create a production branch (e.g., ProdV1.1) off of it—this becomes your official release.Kick Off the Next Cycle
• For the next version, branch a new dev line from your latest production branch (e.g., devV1.2 from ProdV1.1) and repeat.
Update builds daily
What is a “Build”?
A build refers to the process of compiling and assembling all the source code and necessary resources (like images, configuration files, etc.) of a software project into an executable program or a deployable application.
Builds are like magic buttons that can run large projects with a single command.
When your project uses a lot of dependencies and tools, builds become very handy to keep everything working together.
Popular frameworks like Django, Node.js, and others provide built-in build systems.
But when you're working with lower-level languages like C, and building something like a compiler, you often have to set up the build process yourself — using tools like GNU Make.
Understanding Software Builds (in simple terms)
A build is just a packaged version of your project that can be run or deployed. It’s not always the final product, but it’s a working snapshot at that moment.
There are two types:
Full build – compiles everything from scratch.
Incremental build – compiles only what's changed. Much faster for big codebases.
Each build usually gets its own build number, which helps track versions internally.
Modern teams don’t build everything manually. Tools like Make, Maven, Gradle, and CI/CD pipelines (like GitHub Actions, Travis CI, or Jenkins) automate the entire process — from compiling to testing and packaging.
A typical build process looks like this:
Start with source code.
Compile it (turn human code into machine code).
Link it (connect different compiled parts).
Package it (bundle it into a distributable format).
Test it (make sure it actually works).
Some useful tools:
Make – classic tool, rule-based builds.
Maven – used in Java, great for managing dependencies.
CI/CD systems – automate building, testing, and deploying.
Compilers & linkers – convert and connect code into runnable output.
In short, building is what turns your ideas (code) into something real (apps, tools, products). Whether it’s a command line tool or a huge web app — builds are how it all comes together.
GitHub Issues as Bug Database
A Bug Database, also known as a bug tracking system, is a specialized application that helps software development teams manage and track defects (bugs) in their products. It acts as a centralized system for recording, organizing, and monitoring bugs — allowing teams to efficiently track their lifecycle from discovery to resolution.
What a Bug Database Does:
Stores bug reports
Tracks the bug lifecycle
Facilitates team collaboration
Enables reporting and analysis
Helps prevent regressions
It records facts about known bugs. Bug tracking is the process of logging and monitoring bugs or errors during software testing. It's also referred to as defect tracking or issue tracking.
Standard Bug Report Fields
Professional bug trackers typically use structured fields like:
Title/Summary – A short description
Steps to Reproduce – Clear steps to trigger the bug
Actual Result vs. Expected Result
Severity – How badly it affects users
Priority – How urgent it is from a business point of view
Status – New, In Progress, Resolved, Closed, etc.
Environment – OS, browser, device info
Attachments – Logs, screenshots, videos
Assignee – Developer responsible for fixing it
Reporter – Person who reported the bug
Labels/Tags – Component, module, type, etc.
Modern Best Practices
Link bug tickets to commits (e.g.,
Fixes #123)Automate workflows (e.g., auto-close issues when PRs merge)
Use CI pipelines to run tests against fixes
Have an Up-to-date schedule
When you're in a product-making mindset, debug your code. While building a prototype, you don’t need to bring the bug count to zero. But when you're building a product that will serve a large user base, you need to avoid any possible bugs in your code.
You might think you can delay your debugging schedule, but that will prove to be a bad decision. The point is, if you code today and find a bug, you'll easily recall how your code works, making debugging simpler. Otherwise, you might end up wasting a lot of time just trying to understand your own code again before you can even fix it.
Program in a quiet, focused environment
Believe it or not, distractions affect our focus, and focus affects our productivity.
A recent study shows that a student simply having a phone nearby was less productive than a student under the influence of marijuana. Surprisingly, the person who was high performed better than the one distracted by constant phone notifications.
Likewise, in a distracting environment, you're less likely to write quality code compared to working in an isolated, focused setting.
Write Tests
Writing tests for your code isn’t just about catching bugs—it’s about building confidence in your product.
When your tests pass, you know your core features still work after changes.
It makes collaborating with others safer and faster.
Good tests act as a safety net when you refactor or scale.
Start small: test your most important functions, and expand from there.
Build a Team
When interviewing developers, ask them to write code during the interview. This gives you insight into:
• Their thought process
• Code clarity
• Problem-solving skills
Review Usability, UI and UX
You’re not building for yourself—you’re building for your users.
• Usability: Is it easy to use?
• UI: Is it visually appealing and consistent?
• UX: Does it feel smooth and intuitive?
Regularly test with real users—their feedback is gold.
Automate build in one go
One-click builds are a blessing.
• Save time
• Reduce errors
• Improve reliability
Set up build scripts or CI workflows to automatically build, test, and deploy your product.
Final Thoughts
Making a product is a mindset. It’s not about perfect code—it’s about real value, user needs, fast iteration, and continuous improvement.
If you have an idea that you genuinely think is good, don't let some idiot talk you out of it.
Top comments (0)