Trap of Building Projects Instead of Solving Problems

Hey guys, Long time Huh!!

We developers love building things. Give us an idea, a free weekend, and a new tech stack, and we'll probably have an MVP by Monday. But there's one thing we rarely stop to ask: Does anyone actually need this?

Why Solving problems is necessary instead of just building random projects.

We are going to divide it 5 parts and understand the underlying trap of it:

Building Projects
Solving Problems
When and why?
How?
Conclusion

Building Projects

At the beginning of your coding journey it is necessary to learn fundamentals, experiment things, how they work and understand how it’s working under the hood.

We build a shit ton of projects in the beginning and get stuck in the loop of building projects only instead of solving problems.

There are 2 stages of building projects:-

Building to Learn.
Building to Solve.

You would mostly be stuck in the first stage itself.

But I need you to outgrow from 1st stage and move to 2nd stage.

The projects we build in the 1st stage are:

Todo App
CRUD app
Calculator
Stop Watch
Weather app
Password generator
Rebuilding some random project from YT videos.

These are the projects that one can get through online like in 2mins.

You yourself won’t be using these projects.

These may seem cool to you that you’re building, but after a point your learning value eventually diminishes if you're repeatedly building the same things.

You have to level up your game.

Or else you would be stuck in this loop forever.

Solving Problems

This may sound generic to you, but we are talking about actually “PROBLEM SOLVING” here.

Let’s understand what do we mean by problem solving here:

It can be a very specific niche to solve.
Can be a marketplace. (freelance, job).
It can be generic.
Things you face yourself that you want to be solved.

How to identify a problem:-

A problem which you are facing constantly while coding or in any daily task.
People are facing an issue while dealing something related to code or any daily task.
Friends who tell you that they are facing this issue.
It’s not always about the problem also, it could be some repetitive task which you feel bored doing.

These are some examples.

But not every inconvenience is a business opportunity.

Some could be and some may not be.

We should build projects based on 2 things:-

Is it solving my problem?
Or is it solving people’s problem, which they would pay for it to use?

Not every project is meant to be business, some can make sales and some may not.

The idea is to keep identifying the problems & building a software around them which solves it.

Just because you find something annoying doesn't mean other people will pay to solve it.

When & Why?

This is where you’ll get to know when and why to actually move from 1st stage of building to 2nd stage.

So when should a developer stop building tutorial projects?

There are several checkpoints in your coding journey.

Beginner → Intermediate

Intermediate → Advanced.

Advanced → Expert.

In the beginner to intermediate level you build tutorial level projects like mentioned before.

But once you start understanding how things work under the hood.

Why something is happening? Why something is used specifically?

Basically when you can make distinction between multiple things and understand it.

Which is Intermediate → Advanced.

That’s when you should stop seeking projects in YT videos or cloning other projects and seek for the problems worth solving.

When should you start looking for real-world problems?

You see problems everyday in your day to day life.

You get thoughts & ideas of it everyday, wish there was something to solve this, that & etc.

You don't need to stop learning to start solving problems. You need to start applying what you've learned to problems outside tutorials.

You start seeking real world problems which people are facing constantly and want a solution which that they would pay for.

By this time, you shouldn’t be building projects just for the sake of building it or it would look cool on my portfolio.

Why building something for yourself can be a good starting point?

I mentioned above that see problems which you are facing & try to solve it.

By that what i mean is, when you become capable of solving the problem you’re facing then you could easily understand what other people are facing and what kind of solution it needs.

For example:-

I was finding setting up a project boring and messy and it takes time to setup several thing into it. So i built CRAFT, where you can scaffold projects of your own favorite stacks.

You may say that you may not have kind of problems, but mostly you’re wrong, you’re just lazy to sit and brainstorm to do it.

Why?

‘cause building basic projects gives you dopamine than sitting and thinking about a specific problems.

Why you shouldn't immediately jump into building a SaaS just because you have an idea?

SaaS has become a crowded space, especially with the rise of AI.

Everyone has ideas. And almost everyone has access to AI now.

Technical and non-technical people are using AI to turn their ideas into software. Building an MVP has become easier than ever.

But here's the thing: Just because you can build something doesn't mean people need it.

We're seeing more and more products that offer similar features, solve the same problems, and target the same audience.

You might spend weeks building a SaaS, only to realize that people already have alternatives or simply don't care enough about your solution.

I'm not saying you shouldn't build a SaaS. Go ahead and build one.

But before jumping into development, ask yourself a few questions:

Who exactly am I building this for?
What specific problem am I solving?
How are people currently solving this problem?
Why would someone switch to my solution?
Would anyone actually pay for it?

You don't need to have all the answers figured out before writing your first line of code. But you should have enough evidence to believe that you're solving a problem worth solving.

Otherwise, you're not really building a business. You're just building another project with a subscription model.

How?

So how do you identify problems? This is the biggest problem while searching for a problem.

So everyone has ideas right? And everyone uses social media also.

So basically what you guys have to do is, follow along these steps:-

Firstly Identify a problem which could be solved by a software.
Then Identify who all are experiencing the same problem, like categorize them (developers, designers, business, agencies, or any individuals or organizations)
Then talk to them. Talk to all the possible people who you can reach out, (You can use X, Reddit for it, it’s the best way)
Understand what people are doing to solve the problem.
Seek for the existing solutions for the problem, and brainstorm what extra can you add it. if you can’t find any, try to serve a more specific audience.
Find out whether people would actually use or pay for a better solution than currently what they are using.
Build the smallest possible solution. And Launch it.

If you follow these steps, you could actually build projects which people might want to use it.

You don’t need to spend months coding to validate an idea.

Sometimes a google form, landing page, spreadsheet or talking to people, can tell you more than spending 2 weeks building an MVP.

You mostly need 3-4 days to validate an idea. (a week max)

Conclusion

The process of building projects that solve problems isn't as complicated as it sounds.

You just have to be consistent with the process. Stop jumping straight into development every time you get an idea. Take some time to understand the problem, the people facing it, and whether your solution actually makes sense.

Don't build projects just because they make you feel good about yourself. Choose the harder path and do the right thing.

Some of the projects I've worked on along this journey:

Craft: I started building Craft because setting up projects with my preferred tech stack felt repetitive and time-consuming. I wanted a tool that could automate that process. While building it, I realised that making a developer tool work is one thing, but making other developers find it useful is an entirely different challenge. Check out Craft
Persona: With Persona, I explored the digital business card space. I had an idea, designed it, and started building it. But somewhere along the way, I began questioning whether people actually needed another digital business card product. Just because I can build something doesn't mean there's a demand for it. Check out Persona
Reance: Reance was an attempt to explore the freelance marketplace space. I initially focused on building the platform, but gradually realised that the technical implementation was only one part of the problem. Getting clients and freelancers onto the platform, building trust, and creating a marketplace where both sides benefit is a much bigger challenge.

These projects taught me different things, but they all made me question one thing: Am I building something because there's a problem worth solving, or simply because I enjoy building it?

I'm still figuring these things out myself. I haven't mastered the process, and I'm definitely not someone who has built a successful business out of every idea.

But one thing I've started to understand is that writing code is probably the easiest part of building a product. Understanding what to build, who to build it for, and why they would care is much harder.

And maybe that's something we developers need to start questioning more often.

Are we building products because people need them, or because we enjoy the feeling of building something?