Keeping scope focused - how unclear goals kill projects

Burak — Wed, 14 Jan 2026 16:12:15 +0000

"Would our users like it if we added X?"

A seemingly harmless and straightforward question. We want to provide value, so why not implement a new feature?

This is the poison pill a project takes until it reaches a point of paralysis, and eventually gets abandoned. But isn't it natural to introduce new features? How come could it kill a project?

The MVP that's lost in the ocean

Let's say you are building a todo app. The goal is clear: give the user a list, let them check boxes, and hide the completed tasks away.

The team meets up, everyone starts working on their tasks. The week passes.

You gather around a table again. A brilliant idea is proposed: "let's make the list collaborative."

Everyone forgets what they fought for the whole week - and the focus is now collaboration.

The plan is reshaped. MVP will be collaborative. You log off.

When the requirements change...

...at an early stage like this, you have to rethink what you are trying to accomplish.

Each requirement stacks up complexity. Let's think of the requirements that the app would have had without collab:

A single database table for todos
Maybe another table for users if you wanted to do sync
A user interface that consists of maybe 1-2 views.

Let's see what collaboration adds to our stack:

A server is now unavoidable
Not only do you need auth now, you also need access control
Who has what permission in which list?
Invite/share flow?
The original designs now need to change because we need a share UI now
How do we reflect changes in real time again?

Week 3

Collaboration clearly isn't implemented yet, the tickets are sitting on the tracker, but "enthusiasm" is still there.

Everyone in the team wants to create the perfect task tracking app.
Wait, weren't we just doing to-dos? Or so you thought - because next week's focus will be all about implementing a kanban board, status fields, custom properties, Gantt charts, and by the end of the meeting - you went from to-do to reinventing Jira.

You peek at the backlog.
39 tasks - all gray.
You look at the finished tickets - 1 ticket closed in a full week. And it reads "add login ui".

As progression isn't there, the team burns out, and the project gets abandoned.

But we were gonna add AI?

No you won't.

Your requirements should not change at the first week of development. That's like planting onions in a field of roses because "onions got expensive."

Here's the prescription for your next project:

Before writing any code, set your requirements, clearly. Don't make it excessively detailed, but make sure your core value proposition will not change the next day.
Set your roadmap for the MVP. Don't add new features until you launch.
Don't rush the MVP either. The tests you skipped will haunt you in Q3.

Everything else should go to a whiteboard where you can pick ideas from after the launch.

Your project deserves to shine, and your time doesn't deserve to go to waste. So don't let it happen.

Get started with Git

Burak — Sun, 25 Sep 2022 16:38:07 +0000

Hi everyone! Have you ever found yourself in a situation where you broke your perfectly working code and didn't have a backup? If so, you might want to get started with Git. In this post, you will learn to initialize a Git repository, write some code, commit your code and push it to GitHub.

What is Git?

Git is a version control system, developed by Linus Torvalds in 2005. It's used to manage different versions of source code. As an example, you have a program and it has a bug. Someone can fork your code, thus creating a new version of your source code, then implement a fix for the bug, and ask you to merge their changes to your version of the program. During that period, you implement a new feature in another part of your program. How do you combine these two versions? This is what Git does for you. When you accept the other developer's request to merge their code, their changes get applied to the modified files, but your local changes are still in tact. Using Git, every version of your files in a repository are tracked. And the version that acts like a checkpoint, is called a "commit". You can look at the commit history of your repository and get the older version back if something goes wrong.

Installing Git

To use Git, you need to install it first.

On Windows, you can download from Git's website, or use winget to install Git.

On Linux, you can install Git from the repositories of your distribution. The package is usually called git.

On macOS, you can use Homebrew or install XCode.

Creating a repository

Now that you have git installed, it's time to create a repository. You should start by creating a folder for your project. Once you create the folder, open a terminal and set your current directory to the folder.
To initialize a repo, run the git init command. It will initialize the repository with a main/master branch.

Adding a GitHub remote

You created the repository, but you have nowhere to push it yet. For that reason, you should add a remote.

git remote add origin https://github.com/your-name/my-awesome-repo.git

Replace your-name with your GitHub user name, and change the repository name to your own liking.

Creating a README and staging the change

You can start by creating a README.md. Create it in the folder and go back to the terminal.
README.md is currently untracked, and we want it to be tracked. To do this you can run git add ., which will tell Git to track all untracked files.

Creating a commit

Now you can commit your changes to the repository. To do that, run git commit. This will launch an editor (typically vi), in which you can write your commit message. If you want to cancel the commit and go back, you can leave the message empty and the commit will be aborted.

Pushing to GitHub

To push your repo to GitHub, you can do git push origin master, which will push your repository to the origin remote. You will need to authenticate in order to push the repository. You can use the GitHub extension in VSCode to take care of the authentication, or push using the GitHub Desktop app. If you need to push directly from the terminal, you will need to generate an access token on GitHub. You can see the instructions to do that here.

Forem: Burak