Build In Public Journal #2
Hello friend,
Iām excited to share with you what Iāve worked on over the last couple of days. Iām pleased with the progress, refining the idea, buying a domain for the project and starting the research of how open source projects are implemented.
Iām happy to add as many details as possible in these posts, so you can see my thought process and feel inspired to work on your own projects. Also, I really appreciate receiving feedback. Not having a vast amount of experience in contributing to open source projects means I make mistakes. Your feedback is highly appreciated.
A short summary from my previous post: Iāve started the ā12 startups in 12 monthsā challenge. Iām aiming to build a product every month. The one that Iām working on right now is a glossary app. I hope to lower the barrier of entry into the tech industry for newcomers. I want to help people understand difficult tech terms through this open source project. If youāre experienced in the field, please consider getting involved into the project.
This is what happened in the last couple of days:
All the domains are taken
I did a couple of hours of research trying to find a proper domain. There are many great once, but most are taken. The problem is, theyāre not taken and used. I believe some people simply buy and hold onto them. There are many .com, .tech or .io domains that I couldāve used, but they were already taken.

I was trying to find something with glossary. That made sense, but I couldnāt find any available domains that were also short. Actually, I did find some, but they were $9000+ (at least, according to namecheap.com). No way Iām spending that much. I could travel for months with that money. š¤£
Lexicon and wordlist didnāt sound right. The first one felt a bit too serious or academic. The second one made me think of Storybook, for whatever reason.
I thought about explain or define. But again, those domains werenāt available.
But after a while, I finally saw the light at the end of the tunnel. With the help of ChatGPT, I managed to find some domains that were available. I had to choose between:
- geekyterms.com -> This didnāt sound too interesting to me.
- nerdterms.com -> ChatGPT recommend this, but it doesnāt have the right musicality. If I were to tell someone about my product, itās harder to pronounce.
- techterms.io -> This is a good candidate. I wouldāve preferred a .com domain, but this works.
- nerdyterms.com -> This is also a good candidate. It has musicality, it is playful and you get a sense of what itās about right away.
So what did I choose?
I decided to buy two of them: techterms.io and nerdyterms.com. I believe Iāll give them different uses, but for now Iāll use techterms.io for my open source project since it sounds a bit more professional.
Social media
Now that we have a domain, letās create some social media accounts. I donāt know yet which direction the marketing for the project will go, but for now, letās secure some accounts:
- X account - https://x.com/techtermsio
- BSky account - https://bsky.app
- Github organization - https://github.com/techterms
I still need to create some headlines, maybe a logo and do some proper branding. Iāll start on that once I have some project management workflow in place. But for now, we should be good.
Researching - How to move forward
I donāt have much experience with contributing to open source. From what Iāve seen, itās very different from working on a client project. Depending on the project type, how big the team is and how complex the workflow is, there are different approaches to managing projects. Not to say that if youāve worked on some startups, youāve probably noticed that people tend to cut some corners here and there and move faster.
So, creating an open source project thatās reasonably well-written and documented can be difficult. I need to do some research, so follow along.
How to plan and manage the project
Iām starting the learning process by trying to answer this question: āHow do you plan and manage an open source project?ā. I believe I can at least get started by watching what others are doing. I could study some Github open source projects and see how they create issues, how they plan future releases and everything else that goes into project management.
Build Your Own X
Github Repo: https://github.com/codecrafters-io/build-your-own-x
Build Your Own X is a collection of useful links for developers who want to build their own version of a particular software.
Why it might help me: Iām building a glossary app, a collection of definitions. The content of the app will be stored in the repository (same as for Build Your Own X).
This is what Iāve noticed during the research: they donāt have a Github project or milestones to manage releases. They only have issues and pull requests. From a projects management perspective, Iām not sure this is helpful. Iāll keep digging.
In terms of branching strategy, they mainly use main. I believe I need something a bit more complex. Maybe not the full Gitflow, but something in between.
Mockoon
Github Repo: https://github.com/mockoon
Mockoon is an open source software developed by my friend Guillaume that speeds up mock API generation.
Why I think this repo might help me: this is a mature project and Guillaume is a very experienced developer. At first glance, it seems to implement most of Githubās features.
This is what Iāve noticed during the research: he has a dedicated repository for the website (you can check it out here https://github.com/mockoon/mockoon.com). Multiple collaborators are involved in perfecting the project. Thatās also because they followed the best practices like having proper documentation, a code of conduit and clear instructions on how others can contribute to the project.
In terms of project management, they use a simple kanban board for the roadmap (https://github.com/orgs/mockoon/projects/9). They might also have multiple private projects that I donāt know about.
There are two types of issues that they use: bugs and features. Bugs seem to have a predefined, yet a simple straightforward structure: Describe the bug, Steps to Reproduce, and some optional (Screenshots, Product version, Environment version). The features have a more flexible structure from what I can tell. In terms of branching strategy, they seem to be using main and features branches.
Some other useful resources I found:
- https://opensource.guide/starting-a-project/
- https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions
Drawing some conclusions
Based on the research I did, also my experience from past projects, these are some decisions I made in order to manage the project:
- Since Iāll be the only one working on the project at the beginning, Iāll keep the workflow as simple and straightforward as possible.
- We need a Github project and the following issue statuses: backlog, ready, in progress, in review, done
- We need two issue types:
- features - improvements we want to add to the project
- bugs - details about what needs fixing
- We need a contributing guidelines, a README and a Code of Conduct.
- In terms of branching strategy, we could keep things simple for the beginning and have a main branch (thatāll automatically be deployed by Github Actions) and feature and bug branches. Initially, I was considering having a develop branch, but I donāt think this will be necessary since, after the core codebase is ready, we wonāt have many functionality changes, just adding more terms and content.
So letās get some work done
Now that I have the domain, the Github community and the repo, letās get some planning and some work done. Iām trying to document the tasks, but not overcomplicate the whole process. Anyway, I started the work by creating some basic tasks:

You can find the status of the project, the open and closed issues and whatās been done in the Github repository: https://github.com/techterms/techterms
If this projects interests you (and you want me to feel the pressure of having many eyes on my work) you can āļø the project.
Now a personal update
If youāve followed my other social media platforms, you might know that Iām currently in Porto šµš¹. Iām surprised how productive I was this week. I think I should be visiting this amazing city more often and Iād highly recommend visiting Porto!
It has beautiful scenery, amazing food, and there are many tourists around. The city is alive. All the cityās top attractions are within walking distance, but I also have to warn you: walking in Porto feels like a proper workout. It is very hilly, and you spend a lot of time going up and down, up and down. But Iād definitely recommend this city.
At the moment Iām writing this, Iāll be here for another week. Iām not sure how much work Iāll get done next week, since Iāll also be taking some days off from work.
Thank you for reading this weekās article.
See you soon!