DEV Community: Pedro Bustamante

How I think about building mobile apps in 2026

Pedro Bustamante — Sun, 29 Mar 2026 16:50:28 +0000

There are a lot of opinions about how mobile apps should be built.

Frameworks, architectures, best practices… everyone has a take.

But over time, I realized something:

Building apps is less about following rules
and more about making good decisions.

So instead of talking about “the right way,”
this is how I personally think about building mobile apps today.

Start simple (really simple)

It’s very tempting to start with a full structure:

Clean architecture
Multiple layers
Abstractions everywhere

But most apps don’t need that on day one.

What they need is:

To work
To be understandable
To be easy to change

So I start simple.

And only add complexity when it’s justified.

Structure follows problems

I don’t decide architecture upfront anymore.

Instead, I let the app push me toward structure.

If logic starts repeating → I extract
If data sources grow → I separate
If things get hard to maintain → I refactor

Architecture becomes a response.

Not a starting point.

State is the real challenge

Screens are easy.

State is not.

Most of the complexity in mobile apps comes from:

Loading
Errors
Partial data
User actions
Sync

So I spend more time thinking about:

how state flows through the app

than how folders are organized.

The network will fail (plan for it)

Every feature I build has this question behind it:

what happens if this fails?

Because it will.

So instead of assuming success, I design for failure:

retries
fallbacks
clear error states

That alone improves the app more than most patterns.

Don’t fight the platform

This is something I value more and more.

Native platforms exist for a reason.

So instead of trying to abstract everything:

I embrace platform conventions
I keep UI native
I share only what makes sense

That’s why approaches like multiplatform feel more natural.

Optimize for change, not perfection

The goal is not to build the “perfect architecture.”

It’s to build something that can evolve.

Because requirements change.

Ideas change.

Products change.

So the real question becomes:

how easy is this to modify later?

Final thought

Good apps are not built by following patterns blindly.

They’re built by making small, thoughtful decisions over time.

And most of the time…

keeping things simple is the hardest — and most valuable — thing you can do.

Mobile architecture: when it starts working against you

Pedro Bustamante — Mon, 23 Mar 2026 21:57:26 +0000

Lately I’ve been thinking a lot about architecture.

Not from a theoretical point of view, but from something more practical:

why we often end up overcomplicating apps that don’t really need it.

Because if there’s one thing that happens a lot in mobile, it’s this:

we use architectures designed for large systems… in apps that aren’t there yet.

The problem is not the architecture

Architectures like Clean Architecture, MVVM, or similar approaches are not the problem.

They exist for a reason.

The real issue is when and how we use them.

Because many times, we don’t apply them out of necessity…

We apply them because “it’s the right thing to do”.

When everything starts scaling (for no reason)

You start with a simple app.

A couple of screens, some logic, a few network requests.

And suddenly you have:

Use cases
Repositories
Data sources
Mappers
DTOs
Domain models

Everything nicely separated.

Everything looks clean.

But also…

much more complex than the app actually needs.

The invisible cost

That extra complexity isn’t free.

You pay for it with:

More code to maintain
More time to make changes
More friction to understand the flow

And worst of all:

more distance between the idea and the implementation

So… should we avoid architecture?

Not really.

Architecture is necessary.

But it should come as a response to a problem, not as a starting point.

A simpler way to think about it

Instead of asking:

“Which architecture should I use?”

A better question might be:

“What problem am I trying to avoid?”

Frequent changes in logic → introduce abstraction
Multiple data sources → separate layers
Growing complexity → structure things better

If there’s no real problem…

you probably don’t need that much architecture yet.

What changes with experience

Over time, you start to notice a pattern:

The best architectures are not the most “correct” ones.

They are the ones that:

are easy to understand
allow you to iterate quickly
don’t get in your way

The balance

No structure → chaos

Too much architecture → rigidity

The interesting part is in the middle.

And there’s no exact formula.

Final thought

Good architecture is not about adding more layers.

It’s about making things easier to change.

And many times, the simplest solution is already the right one.

The hard part is knowing when to stop.

Overengineering is not about writing more code.

It’s about solving problems you don’t have.

Kotlin in 2026: what’s actually happening (and why it’s still a smart bet)

Pedro Bustamante — Sat, 21 Mar 2026 22:14:16 +0000

If you search for “Kotlin in 2026,” you’ll probably find rankings, stats, and comparisons.

But the truth is, those numbers don’t tell the whole story.

Because Kotlin is no longer “the language of the future.”

And honestly, that’s exactly what makes it interesting.

Where Kotlin stands today

A few years ago, Kotlin was everywhere. Lots of hype, lots of discussion, lots of expectations.

Today, that noise has gone down.

At first glance, it might seem like it lost momentum.

But when you look at it from the inside — working in mobile or close to the ecosystem — something different is happening: Kotlin didn’t fade away, it settled.

It found its place.

Android doesn’t really exist without Kotlin anymore

In the Android world, Kotlin stopped being optional a long time ago.

It’s not something teams debate anymore. It’s not a technical decision you need to justify.

It’s just… what people use.

Everything modern revolves around it: architectures, tooling, libraries. Even when there’s legacy Java code, the natural path is often to gradually move toward Kotlin.

And that creates something important: stability.

Where things are really moving: Kotlin Multiplatform

If there’s one area pushing Kotlin forward right now, it’s Multiplatform.

And not because of promises, but because of how it solves a very real problem: sharing logic without giving up native.

For years, cross-platform solutions tried to abstract everything.

Sometimes it worked… sometimes not so much.

Kotlin takes a different approach.

It lets you share what actually makes sense (business logic, data, rules), while keeping each platform truly native.

And in real teams, that makes a big difference.

Because you’re not fighting the tool.

So… why isn’t everyone talking about Kotlin?

Because it’s not trying to be the most popular language.

It’s not competing in the same space as JavaScript or Python.

And if you only look at rankings, that can make it seem less relevant.

But that’s also part of its advantage.

Kotlin grows in very specific places:

Modern mobile development
Teams that care about architecture
Projects built with long-term quality in mind

It doesn’t make a lot of noise… but it sticks.

The job market (a more honest take)

There aren’t as many job listings as JavaScript or Python. That’s true.

But there also isn’t the same level of competition.

And teams using Kotlin are often not random. They tend to be more intentional, more structured, more focused on doing things right.

That changes the kind of opportunities you find.

What really changed (and why it matters)

Kotlin used to be the “new thing.”

Now it’s infrastructure.

And that’s a big shift.

Because the languages that last aren’t the ones with the most hype — they’re the ones that quietly become part of the stack.

So… is Kotlin worth it in 2026?

If you’re in mobile, yes.

If you care about building things properly, also yes.

And if you combine it with backend or multiplatform, even better.

It’s not the language that’s going to dominate everything.

But it doesn’t need to.

Final thought

Some languages grow fast and make a lot of noise.

Others become essential without trying too hard.

Kotlin is closer to the second group.

And in a long-term career, that’s usually a very good place to be.

- From my experience working in mobile, this shift feels very real.