Starting Your Own Side Project: Where to Begin

If you’re new to the world of coding, the sheer number of available technologies can feel overwhelming when starting your own project. Frameworks, libraries, databases, hosting options—there’s a lot to choose from, and it’s easy to get stuck before you even begin.

At this stage, you usually have two options:

1. Complex Project → Stick to What You Know

If your idea is ambitious and requires a lot of moving parts, it’s best to pick technologies you already know and enjoy working with. This will make coding smoother and save you from constantly battling with tools you’re not yet comfortable with. The focus should be on building your project, not getting stuck on unfamiliar errors.

2. Simple Project → Experiment with Something New

If the project is small and manageable, it’s a perfect opportunity to explore a new technology. In that case, the question becomes: which technology should I pick?

Check which frameworks and tools are currently popular.
Browse job postings to see which skills are in demand.
Think about what excites you—motivation matters when learning something new.

Once you’ve chosen the technology, you already have a strong starting point. The decision of what tools to use will guide the rest of your project and give you confidence to take the first real step.

Keep It Minimal and Focus on Logic First

Remember: your project will evolve naturally. Many technologies will come into play only in later stages, so there’s no need to install everything “just in case” from the beginning. Often, some tools turn out to be unnecessary because they don’t fit the project, or they are simply overkill.

At the start, use only what you need right now—nothing for the future. For example, you might think about adding documentation tools, but if you’re not going to write the docs immediately, don’t set up the technology yet. You might later decide the project is too simple for it, or that it’s just for learning, and setting it up would be unnecessary work.

Logic Before Style

A common mistake is to start by making the app look perfect—designing the UI, writing all the styles—and only then implementing the logic. I’m not a fan of this approach. It’s usually better to start with the logic. Your application may look ugly at first, but this has real advantages:

You don’t waste time designing UI or writing styles too early.
You have less code to manage initially, because everything related to styling is postponed.
Fewer files make it easier for beginners to understand and navigate the project.

Starting with logic first keeps your project simple, focused, and much easier to iterate on.

Breaking Down Your Project

Before you write a single line of code, it’s worth taking a moment to outline what your application should do. Even a simple sketch on a piece of paper can make a big difference.

If you have limited experience communicating with clients, this step is an excellent opportunity to practice. Write your project description as if you were explaining it to a non-technical person. For example, instead of detailing exactly how data will be sent, sorted, and stored on a server, you could write:

“The application should allow users to add data and save it to the server.”

Treat this as an exercise—this is exactly how clients usually describe their requirements. Once you have this high-level description, you can break the project into tasks and decide whether to start with something simple or tackle the most challenging features first.

Where to Start?

It depends on the project. Take, for example, a photo-editing app. It makes sense to start with the core functionality—in this case, the canvas. Focus on making it responsive and solid, so adding new features later won’t become a headache. Building a strong foundation first will make the rest of the project much smoother and more manageable.

Another good guideline is to start with the smallest elements that will be used repeatedly throughout the application. If you’re not sure where to begin, these small, reusable pieces are usually the best starting point.

This is also the perfect time to think about the direction of your app, which can give you several benefits:

You might decide to apply a design pattern from the beginning.
You can identify which elements need to be flexible because they’ll be used multiple times.

Taking a moment to plan your foundation before diving into endless new features makes future development much easier. After all, the goal is to keep expanding the app as simple and manageable as possible.

Reusable Logic

For me, reusable logic is not as obvious as reusable components. It’s often hard to predict which parts of your code will be used in multiple places in your application. Here are some guidelines that have worked well for me:

Don’t worry about constantly changing and improving your code. In fact, you can take pride in it - seeing opportunities to simplify, reduce, or make your code more abstract is part of the learning process.
Keep your code as simple as possible. For example, if you need a function to add two numbers, don’t try to over-engineer it to sum an array of numbers. Sure, that’s more flexible and abstract, but it’s unnecessary at this stage. Focus on the immediate problem. If you ever need a more general solution later, you can refactor your original function at that point.
Extract repeated logic. If you notice that a piece of logic is being repeated, move it into a separate function. Later, you might even put it in its own file so that it can be imported wherever it’s needed in the project.

The Importance of Comments

Never underestimate the power of comments. Memory is unreliable, and after some time, you might struggle to understand your own code. Many developers avoid writing comments, and I’ve seen firsthand why that’s a mistake.

In one company I worked for, they skipped documentation and comments to “save time.” This approach had severe consequences:

Implementing new features became much harder because you often had to write logic from scratch or search through the code to see if something similar already existed.
It caused a lot of repeated logic in slightly different versions, which could have been avoided with a little abstraction.
Understanding what each function does—what parameters it accepts, what it returns—was a challenge, especially in plain JavaScript without TypeScript.
New team members had to spend huge amounts of time figuring out existing code.

After some time, I got used to it, but it was still incredibly inefficient. This is why comments are your best friend. I love writing them and documenting everything “for an idiot,” because when you come back to a project after months, you’ll appreciate having clear explanations—even if it feels obvious now.

Writing good comments and documentation saves time, reduces errors, and makes your project much more maintainable for both you and anyone else who works on it in the future.

How to Handle Problems

When you start developing your application, there will inevitably be moments when you face critical problems. Often, these issues arise from gaps in your knowledge—but don’t worry, no one knows everything.

In these situations, it’s useful to:

Check the documentation of the technology you’re using.
Search online, for example on Stack Overflow, for solutions or similar problems.

If the problem isn’t about the technology itself, but rather you just don’t know how to solve it yet, it’s perfectly fine to leave it for later. Taking a break from a tricky problem can be the best thing you do. Sometimes, after stepping away, a solution or new approach will become clear.

I’ve often encountered problems that seemed impossible to solve. Hours of debugging and searching for solutions brought no results. My brain became so exhausted that I couldn’t think clearly at all. In those cases, simply stepping away - going for a walk, taking a nap, or sleeping overnight - often made the problem appear trivial the next day and solvable in just a few minutes.

Meanwhile, you can focus on another part of your application, making progress instead of wasting time stuck on something you currently can’t resolve. This approach keeps your momentum and prevents frustration from slowing you down.

Final Thoughts

Remember: large applications aren’t built in a few hours. Developing a substantial project often takes months or even years, especially if you’re working alone.

Don’t get discouraged when you encounter difficult problems—they’re a natural part of the process. At the same time, make it easy for yourself to return to your code after a break by writing clear comments and documentation. This ensures that even after weeks or months away, you can quickly understand what you wrote and continue making progress without losing momentum.

Building a side project is a marathon, not a sprint. Take it step by step, focus on the core first, keep your logic simple, and plan for reusability. With patience, persistence, and good habits, you’ll not only create a functional application but also grow tremendously as a developer.