Simone Montalto

Good support is not about solving problems quickly.
It is about listening well enough to make fewer problems appear in the future.
It is slow, intentional and incredibly valuable.

I think this is why I still reply to every message personally.
It is exhausting sometimes, but it keeps me grounded.
It reminds me that the app is not an abstract system.
It is something people use in their daily life, and they trust me with it.

Support forces me to take responsibility for every decision I made.
There is no buffer, no team to hide behind, no automated response system.
It is just me, the product I shaped, and the person trying to understand it.

Some messages remind me that people bring their own emotions into the app.
A lost backup is not just lost data.
It is hours of reading, memories, lists that matter.
You cannot answer those emails with distance.
You need to understand the weight of what they are describing.

Support also reveals mistakes I made in design.
If someone cannot find a feature, the feature is poorly placed.
If several people misunderstand the same icon, the icon is wrong.
If a process feels confusing, the confusion is mine, not theirs.

How they organize their books, how they track their habits, how their workflow breaks when something unexpected happens.
These details never emerge from analytics.
They only appear in conversation.

Answering support emails is not the most glamorous part of building apps, but it is the one that teaches me the most.
It is the closest I ever get to seeing how people actually use what I create. Users rarely write just to report a bug. They write to share a piece of context.

Sync is not the most visible feature in an app, but it is the backbone of everything that feels seamless.
And most of the engineering behind it is invisible by design.

The goal is to make sync feel quiet.
No waiting, no warnings, no decisions to make.
Just the sense that your library follows you without asking for attention.
When that feeling appears, you know the architecture is right.

There is also the human side.
When sync fails, users lose trust quickly, even if they do not lose data.
A single bad experience can make the entire app feel unsafe.
This is why reliability matters more than speed or cleverness.

Most of the work happens before writing code.
You have to plan how data moves, what operations are allowed, how conflicts are resolved and what the app should do when something unexpected happens.
A sync model without clear boundaries will break in unpredictable ways.

You also have to deal with state conflicts, partial updates, connectivity issues, retries, atomicity and the fact that users expect instant consistency even when the underlying system cannot guarantee it.
iCloud is powerful, but it is not magic.
You have to design around its rules.

People often imagine sync as “uploading data somewhere”.
In reality it is about reconciling different timelines.
A user edits a book on the iPhone while the iPad is offline.
Later they delete the same book on the Mac.
Which version is the truth?
The answer cannot rely on luck.

Sync is one of those features that looks simple from the outside and incredibly complex from the inside.
When it works, no one notices it.
When it fails, everything else in the app becomes unreliable.
That is why designing sync is mostly about avoiding fragility.

Designing without metrics is harder, but it keeps the product aligned with its values.
It makes every decision intentional.
And for the kind of apps I build, that matters more than any curve trending upward.

I prefer my apps to grow slowly but honestly.
No manipulation, no data harvesting, no hidden incentives.
Just tools that respect the fact that people have limited time and a clear purpose.

The truth is that optimizing for numbers often means optimizing against the user.
You design flows that increase activity instead of satisfaction.
You measure friction instead of trust.
In the end you get growth, but you lose intention.

Building without metrics also changes the tone of the product.
There is no gamification, no push to stay longer, no tricks to increase engagement.
If a user opens the app for ten seconds and closes it, that is success.
The app helped them and then stepped aside.

But that limitation forces clarity.
I cannot rely on analytics to fix bad design.
I have to understand the intent behind every feature before shipping it.
If it is not simple enough to stand on its own, the idea is probably weak.

When I decided not to track anything in my apps, I had to accept a different kind of uncertainty.
I cannot see where users tap, which screens they abandon, or how long they stay.
If something is confusing, I find out only when someone writes to me.

Most apps today are built around numbers.
Clicks, conversions, funnels, retention curves.
Metrics can be useful, but they also change the way you think about your product.
You stop designing for people and start designing for graphs.

Good UX is not a big moment.
It is a collection of tiny decisions that make the interface feel calm and intentional.
Most people will never know what changed, but they will feel it.
And that is the point.

I think this is why small adjustments matter.
They are not decorative.
They are signals.
They tell you whether the product is growing in the right direction, or whether you are accumulating noise without noticing.

These refinements also reveal hidden design mistakes.
If aligning a section requires a hack, the layout is probably wrong.
If spacing looks bad in one configuration, the structure is not flexible enough.
Details show you where the architecture needs clarity.

Fixing these details does not give you a new feature to announce, but it changes how the app feels.
It makes the interface quieter.
More predictable.
More respectful of the user’s time and attention.

A few days ago I spent half an afternoon adjusting the spacing in a view that most users open for a few seconds.
Technically nothing was broken, but something felt off.
Too tight in some places, too loose in others.
The kind of imbalance that creates a background discomfort.

When people talk about UX they usually think about big redesigns or major features, but most of the experience is shaped by the smallest details.
Margins, timing, alignment, typography, animations that last just long enough.
Things you do not notice unless they are wrong.

When people say a feature feels natural, what they are noticing is not the code but all the things I chose not to include.
Most of the design process is invisible, but it is where the product actually takes shape.

Only after that I start writing code.
By then the feature has already lived several iterations on paper, and coding becomes almost the easy part.
The real work was in deciding what the feature should be allowed to do.

Once the direction is clear, I try to break the feature.
What happens if sync conflicts?
What if the user has ten thousand items?
What if they use it in a way I did not expect?
Good design is what survives these questions.