From Android Freelancer to Full-Stack: How My Stack Evolved

If you ask “what’s your main stack,” my answer has changed quite a bit over the past few years. Here’s a rundown of that path, and why I don’t regret any of the shifts — though honestly, in the middle of it, it often felt like I never got to actually get “good” at one thing before moving on to something new.

The Android phase (2019—2023)

I started as an Android freelancer at Koding Works — building Android apps, collaborating across teams on new features, fixing bugs and performance issues. The focus was narrow but deep: native UI, Activity/Fragment lifecycle, REST API integration to a backend usually handled by another team. Those four years weren’t wasted time — the mindset around lifecycle and resource constraints from Android ended up transferring to other areas later, though I didn’t know that at the time.

Branching into full-stack web

Alongside and after that Android phase, I started taking on both backend and frontend web work — React on the client side, Spring Boot for Java-based backends, plus exploring Python and Go for lighter services. The push wasn’t some idealistic “I want to be full-stack” — it was more direct than that: freelance clients often didn’t have a separate backend team. If I could only do Android, I’d lose out on projects that needed a full end-to-end solution — and as a freelancer, losing a project means losing income, not just a shame.

Learning full-stack early on wasn’t as smooth as this summary makes it sound. The first few months I made architecture decisions I later realized were wrong — coupling logic that should’ve lived in the backend into the frontend instead, just because I was more comfortable there at the time. It took a while to recalibrate what was actually best practice versus what was just an old mobile-world habit that didn’t translate to the web.

The cross-platform desktop phase (2023—present)

Since June 2023 I’ve been at Hantechno, building cross-platform desktop apps for VPN connections, remote desktop, and security reporting, using Avalonia (C#), Golang, and Python depending on what each module needed. This is an area I barely touched early in my career, and honestly, when this project first got offered to me, I hesitated — desktop apps are a different world from the web or mobile work I already knew. It turned out a lot of the fundamentals (state management, networking, concurrency) transferred well from mobile and web experience, even though the syntax and tooling were completely different.

What I learned from this transition

A specific stack is a tool, not an identity. The fundamentals that actually matter — problem solving, quickly reading unfamiliar documentation, and the discipline to write code other people can maintain — are what’s portable across platforms. Languages and frameworks get picked up as needed. What I didn’t expect: the more I switched stacks, the faster I got at picking up the next one, because I got better at recognizing which patterns are universal (state management, error handling, testing) and which are specific to one ecosystem alone.