It’s typical.

I want to write another article, but my blog is down again. Why? Attacks. Of course. Never mind.

I’m still writing this because this week I want to talk about solo development. Today I have a migraine and I’m lying in bed trying to feel productive while watching Gossip Girl and writing this article. Honestly, that feels like peak senior-engineer multitasking.

I became a solo developer three years ago and I absolutely love it.

Originally, I wanted to work in mobile development, but getting the first opportunity was difficult. Before that, I worked as a full-stack Java developer and, honestly, I was quite unhappy. It was programming, yes — but not the kind I dreamed about. Mobile development was always the goal from the moment I started coding.

After being laid off, I started rebuilding from scratch. Backend development during the day, Android tutorials at night, and a slightly unhealthy amount of coffee in between.

And then suddenly?

Full-time mobile developer.

Funny how life works.

The Shift Between Engineer and Builder

One of the biggest mindset changes happens when you stop being “just an engineer” and start becoming a builder.

As an engineer in a company, I mostly implemented ideas. Product managers made product decisions, designers created experiences, stakeholders debated priorities, and engineers executed.

As a solo builder, everything changes.

You still listen — but now you listen to customers.

You start noticing what annoys people in everyday apps. You listen when your friends complain about confusing UX. You observe patterns. Suddenly, random conversations become product research.

And the result?

At 22:00, while trying to sleep, you are writing notes about a “new grill mode” feature for your weather app because someone casually mentioned they wanted to know if Saturday barbecue conditions would be acceptable.

This is the difference.

In a Company

• Specialized roles
• Shared ownership
• Process safety nets
• Multiple approval layers
• Somebody else usually decides priorities

Solo Development

• One person owns everything
• Every abstraction has a cost
• Over-engineering becomes visible immediately
• Technical debt becomes personal debt
• There is nobody else to blame for bad UX

Which is terrifying.

And also incredibly freeing.

What “Software Engineering for One” Actually Means

Solo development is not:

• an AI hype cycle
• “Become a 10x engineer in 14 days” courses
• buying another productivity app you will never open again

It means owning the entire product.

You make product decisions, technical decisions, business decisions, and sometimes even customer support decisions while eating dinner.

You stop optimizing for “perfect architecture presentations” and start optimizing for:

• shipping
• maintainability
• customer feedback
• sustainability

Because at the end of the day, users do not care whether you used Clean Architecture, Hexagonal Architecture, Onion Architecture, or the Architecture of Ancient Rome.

They care whether the app works.

And whether it crashes when they open it.

Solo engineering means:

• making product, technical, and business decisions alone
• balancing speed versus maintainability
• intentionally choosing simplicity
• accepting trade-offs early
• understanding that every additional abstraction is future work for… you

And that last part changes your perspective very quickly.

Starting With the Wrong Assumptions

As a junior developer, I thought the most important thing was writing good code.

As a mid-level developer, I thought the most important thing was sustainability.

As a senior developer?

Scalability, accountability, and understanding trade-offs.

But here is the funny part:

One of the biggest mistakes in solo development is optimizing too early for problems you do not even have yet.

In companies, scalability matters.

When you have millions of users, scalability is survival.

But when you have zero users?

You do not need a scalable app.

You need an app.

I see many developers focusing on frameworks, cloud technologies, microservices, Kubernetes, architecture diagrams, and scalability strategies before they even have users.

Meanwhile, their actual users — approximately 2.5 people — are trying to tell them that the onboarding screen is confusing.

That is the real problem.

If you already have users, listen to them.

The most dangerous thing in solo development is building impressive technical solutions for problems nobody actually experiences

Why a Weather App?

Because I had data.

And data is a huge advantage.

I started learning Android development around three years ago. I loved mobile development immediately, but before that I worked mostly as a backend developer.

The problem?

Nobody wanted to hire a mobile developer with zero mobile experience.

Which is understandable.

Slightly painful, but understandable.

So I joined a smaller company specializing in weather technologies.

During that time, I studied Android and iOS ecosystems constantly. Eventually, I found a mobile development role, and later I started working on a small weather application built mainly to showcase weather data.

And honestly?

I absolutely adored that project.

Not because it was the next billion-dollar startup.

But because it solved a real problem with data I understood deeply.

That matters more than people think.

A lot of solo developers start with random ideas.

But when you already understand an industry, already know the users, and already have access to data or experience, you start with an enormous advantage.

Sometimes the best startup idea is simply:

“I know this problem really well.”

Engineering Skills That Matter More in Solo Development

Interestingly, some skills become far more important when you work alone.

Not algorithms.

Not advanced architecture patterns.

Not writing LinkedIn posts about distributed systems.

The truly important skills are much less glamorous.

Consistency Over Intensity

Working 16 hours for three days and then disappearing for two weeks is not sustainable.

Small progress every day wins.

Especially when you are alone.

Scope Management

This one hurts.

Every solo developer starts with:

“Simple app idea.”

Three weeks later:

• AI integration
• offline mode
• analytics dashboard
• smart recommendations
• Apple Watch support
• somehow also a social network

Learning what not to build is one of the most valuable engineering skills.

Knowing When “Good Enough” Is Enough

Perfectionism is dangerous in solo development.

Sometimes the correct engineering decision is:

“This works. Ship it.”

Not because quality does not matter.

But because unfinished perfect software is still unfinished.

Conclusion — How Working as a Solo Android Engineer Helped Me

Working solo changed the way I think about software engineering completely.

It taught me:

• maintainability matters more than cleverness
• debugging discipline saves enormous amounts of time
• release processes are part of engineering, not an afterthought
• users are more important than architecture debates
• technical debt should be handled consciously, not emotionally

Most importantly, it taught me that software engineering is not only about writing code.

It is about building something useful.

And sometimes that means writing product notes at 22:00 while lying in bed with a migraine and watching Gossip Girl.

Which, surprisingly, is still better than another Kubernetes tutorial nobody asked for.