Simone Montalto
@simonemontalto.bsky.social
Indie Developer on iOS and macOS 👨💻 Creator of Book Tracker 📚 Movie Tracker 🍿 Music Tracker 🎶 Habit Tracker 🎮 Game Tracker 🧘 Countdown Widget 📆
In the end, a good indie app is not just a tool.
It is a conversation between the developer and the user.
Quiet, simple and built with the kind of intention that does not scale but does endure.
It is a conversation between the developer and the user.
Quiet, simple and built with the kind of intention that does not scale but does endure.
November 26, 2025 at 2:30 PM
In the end, a good indie app is not just a tool.
It is a conversation between the developer and the user.
Quiet, simple and built with the kind of intention that does not scale but does endure.
It is a conversation between the developer and the user.
Quiet, simple and built with the kind of intention that does not scale but does endure.
This is the part of indie development that I love the most.
Not that I get to build whatever I want, but that I get to build things that feel aligned with how I think.
If the apps feel human, it is because they come from a human, not from an optimisation process.
Not that I get to build whatever I want, but that I get to build things that feel aligned with how I think.
If the apps feel human, it is because they come from a human, not from an optimisation process.
November 26, 2025 at 2:30 PM
This is the part of indie development that I love the most.
Not that I get to build whatever I want, but that I get to build things that feel aligned with how I think.
If the apps feel human, it is because they come from a human, not from an optimisation process.
Not that I get to build whatever I want, but that I get to build things that feel aligned with how I think.
If the apps feel human, it is because they come from a human, not from an optimisation process.
Some people see indie apps as small versions of bigger ones.
I see them as personal artefacts.
They are not defined by scale, but by intention.
They carry the biases, the limits and the care of the person who built them.
I see them as personal artefacts.
They are not defined by scale, but by intention.
They carry the biases, the limits and the care of the person who built them.
November 26, 2025 at 2:30 PM
Some people see indie apps as small versions of bigger ones.
I see them as personal artefacts.
They are not defined by scale, but by intention.
They carry the biases, the limits and the care of the person who built them.
I see them as personal artefacts.
They are not defined by scale, but by intention.
They carry the biases, the limits and the care of the person who built them.
As a solo developer, I cannot separate the product from the person.
Every time I say no to a feature, I am protecting something that matters to me.
Every time I refactor code, I am shaping the app in a direction that feels more honest.
Every time I say no to a feature, I am protecting something that matters to me.
Every time I refactor code, I am shaping the app in a direction that feels more honest.
November 26, 2025 at 2:30 PM
As a solo developer, I cannot separate the product from the person.
Every time I say no to a feature, I am protecting something that matters to me.
Every time I refactor code, I am shaping the app in a direction that feels more honest.
Every time I say no to a feature, I am protecting something that matters to me.
Every time I refactor code, I am shaping the app in a direction that feels more honest.
You also see this in the things I deliberately do not build.
No recommendations, no automated behaviour, no attempts to influence user decisions.
Not because these things are bad, but because they do not match how I want tools to behave in my own life.
No recommendations, no automated behaviour, no attempts to influence user decisions.
Not because these things are bad, but because they do not match how I want tools to behave in my own life.
November 26, 2025 at 2:30 PM
You also see this in the things I deliberately do not build.
No recommendations, no automated behaviour, no attempts to influence user decisions.
Not because these things are bad, but because they do not match how I want tools to behave in my own life.
No recommendations, no automated behaviour, no attempts to influence user decisions.
Not because these things are bad, but because they do not match how I want tools to behave in my own life.
Even the structure of the UI mirrors how I think.
I like clarity, predictable navigation and features that stay quiet until the user needs them.
This is why the apps feel calm.
Not by design trend, but by personality.
I like clarity, predictable navigation and features that stay quiet until the user needs them.
This is why the apps feel calm.
Not by design trend, but by personality.
November 26, 2025 at 2:30 PM
Even the structure of the UI mirrors how I think.
I like clarity, predictable navigation and features that stay quiet until the user needs them.
This is why the apps feel calm.
Not by design trend, but by personality.
I like clarity, predictable navigation and features that stay quiet until the user needs them.
This is why the apps feel calm.
Not by design trend, but by personality.
My apps do not track anything because I do not like being tracked.
They avoid noise because I avoid noise.
They do not push notifications unless absolutely necessary because I dislike being interrupted.
These are not marketing angles.
They are personal defaults expressed in software.
They avoid noise because I avoid noise.
They do not push notifications unless absolutely necessary because I dislike being interrupted.
These are not marketing angles.
They are personal defaults expressed in software.
November 26, 2025 at 2:30 PM
My apps do not track anything because I do not like being tracked.
They avoid noise because I avoid noise.
They do not push notifications unless absolutely necessary because I dislike being interrupted.
These are not marketing angles.
They are personal defaults expressed in software.
They avoid noise because I avoid noise.
They do not push notifications unless absolutely necessary because I dislike being interrupted.
These are not marketing angles.
They are personal defaults expressed in software.
I no longer feel embarrassed by my old code.
It is not who I am today, but it is part of how I got here.
And in a strange way, it keeps me honest.
It reminds me that in a few years, today’s code will also look unfamiliar.
And that is exactly how it should be.
It is not who I am today, but it is part of how I got here.
And in a strange way, it keeps me honest.
It reminds me that in a few years, today’s code will also look unfamiliar.
And that is exactly how it should be.
November 25, 2025 at 3:45 PM
I no longer feel embarrassed by my old code.
It is not who I am today, but it is part of how I got here.
And in a strange way, it keeps me honest.
It reminds me that in a few years, today’s code will also look unfamiliar.
And that is exactly how it should be.
It is not who I am today, but it is part of how I got here.
And in a strange way, it keeps me honest.
It reminds me that in a few years, today’s code will also look unfamiliar.
And that is exactly how it should be.
Maintaining apps with different ages teaches you something important.
Growth does not happen in big leaps.
It happens quietly, diffused across thousands of lines of code and hundreds of decisions you barely remember making.
Growth does not happen in big leaps.
It happens quietly, diffused across thousands of lines of code and hundreds of decisions you barely remember making.
November 25, 2025 at 3:45 PM
Maintaining apps with different ages teaches you something important.
Growth does not happen in big leaps.
It happens quietly, diffused across thousands of lines of code and hundreds of decisions you barely remember making.
Growth does not happen in big leaps.
It happens quietly, diffused across thousands of lines of code and hundreds of decisions you barely remember making.
What changes most over the years is not the syntax but the mental model.
You become more patient, more pragmatic, more willing to let go of elegant solutions in favour of resilient ones.
You stop fighting the framework and start working with it.
You become more patient, more pragmatic, more willing to let go of elegant solutions in favour of resilient ones.
You stop fighting the framework and start working with it.
November 25, 2025 at 3:45 PM
What changes most over the years is not the syntax but the mental model.
You become more patient, more pragmatic, more willing to let go of elegant solutions in favour of resilient ones.
You stop fighting the framework and start working with it.
You become more patient, more pragmatic, more willing to let go of elegant solutions in favour of resilient ones.
You stop fighting the framework and start working with it.
Sometimes you fix something and realize the old version was not wrong, it was built for constraints that no longer exist.
Other times you discover a clever trick you forgot you ever wrote.
Past you was not always misguided.
Other times you discover a clever trick you forgot you ever wrote.
Past you was not always misguided.
November 25, 2025 at 3:45 PM
Sometimes you fix something and realize the old version was not wrong, it was built for constraints that no longer exist.
Other times you discover a clever trick you forgot you ever wrote.
Past you was not always misguided.
Other times you discover a clever trick you forgot you ever wrote.
Past you was not always misguided.
Working across these layers of past experience is humbling.
You want to rewrite everything, but rewriting is almost never the right solution.
Old code carries context.
It reminds you how the app evolved and why certain decisions were made.
You want to rewrite everything, but rewriting is almost never the right solution.
Old code carries context.
It reminds you how the app evolved and why certain decisions were made.
November 25, 2025 at 3:45 PM
Working across these layers of past experience is humbling.
You want to rewrite everything, but rewriting is almost never the right solution.
Old code carries context.
It reminds you how the app evolved and why certain decisions were made.
You want to rewrite everything, but rewriting is almost never the right solution.
Old code carries context.
It reminds you how the app evolved and why certain decisions were made.
The two year old app is where things finally click.
Structure is clearer, responsibilities are cleaner, fewer magic shortcuts, fewer hidden traps.
It is not perfect, but it has intention.
It reflects a way of thinking that became more stable.
Structure is clearer, responsibilities are cleaner, fewer magic shortcuts, fewer hidden traps.
It is not perfect, but it has intention.
It reflects a way of thinking that became more stable.
November 25, 2025 at 3:45 PM
The two year old app is where things finally click.
Structure is clearer, responsibilities are cleaner, fewer magic shortcuts, fewer hidden traps.
It is not perfect, but it has intention.
It reflects a way of thinking that became more stable.
Structure is clearer, responsibilities are cleaner, fewer magic shortcuts, fewer hidden traps.
It is not perfect, but it has intention.
It reflects a way of thinking that became more stable.
The three year old codebase is more balanced.
Some parts feel solid, others feel cautious.
You can tell I was starting to understand what long term maintenance truly means.
You see the moment where you stopped writing code for yourself and started writing it for the future version of you.
Some parts feel solid, others feel cautious.
You can tell I was starting to understand what long term maintenance truly means.
You see the moment where you stopped writing code for yourself and started writing it for the future version of you.
November 25, 2025 at 3:45 PM
The three year old codebase is more balanced.
Some parts feel solid, others feel cautious.
You can tell I was starting to understand what long term maintenance truly means.
You see the moment where you stopped writing code for yourself and started writing it for the future version of you.
Some parts feel solid, others feel cautious.
You can tell I was starting to understand what long term maintenance truly means.
You see the moment where you stopped writing code for yourself and started writing it for the future version of you.
The six year old codebase is a snapshot of the person I was when everything was new.
Different patterns, different assumptions, different fears.
I was more defensive, less confident, sometimes too clever, sometimes not clever enough.
Reading it now is strange but also grounding.
Different patterns, different assumptions, different fears.
I was more defensive, less confident, sometimes too clever, sometimes not clever enough.
Reading it now is strange but also grounding.
November 25, 2025 at 3:45 PM
The six year old codebase is a snapshot of the person I was when everything was new.
Different patterns, different assumptions, different fears.
I was more defensive, less confident, sometimes too clever, sometimes not clever enough.
Reading it now is strange but also grounding.
Different patterns, different assumptions, different fears.
I was more defensive, less confident, sometimes too clever, sometimes not clever enough.
Reading it now is strange but also grounding.
In the end the real goal is not to eliminate every unpredictable behaviour.
It is to build a product that recovers gracefully, even when the unexpected happens.
This is what makes good software feel solid, even when the code behind it is constantly evolving.
It is to build a product that recovers gracefully, even when the unexpected happens.
This is what makes good software feel solid, even when the code behind it is constantly evolving.
November 24, 2025 at 5:24 PM
In the end the real goal is not to eliminate every unpredictable behaviour.
It is to build a product that recovers gracefully, even when the unexpected happens.
This is what makes good software feel solid, even when the code behind it is constantly evolving.
It is to build a product that recovers gracefully, even when the unexpected happens.
This is what makes good software feel solid, even when the code behind it is constantly evolving.
What these bugs teach you is not just patience.
They teach you humility.
Software is full of invisible states and unpredictable interactions.
Even simple apps hide a world of complexity behind the surface.
They teach you humility.
Software is full of invisible states and unpredictable interactions.
Even simple apps hide a world of complexity behind the surface.
November 24, 2025 at 5:24 PM
What these bugs teach you is not just patience.
They teach you humility.
Software is full of invisible states and unpredictable interactions.
Even simple apps hide a world of complexity behind the surface.
They teach you humility.
Software is full of invisible states and unpredictable interactions.
Even simple apps hide a world of complexity behind the surface.
Often the fix is not dramatic.
A missing guard, a race condition, an assumption that does not hold in certain contexts.
Tiny things with big consequences.
You patch them carefully, test again and hope that the silent chain of events no longer appears.
A missing guard, a race condition, an assumption that does not hold in certain contexts.
Tiny things with big consequences.
You patch them carefully, test again and hope that the silent chain of events no longer appears.
November 24, 2025 at 5:24 PM
Often the fix is not dramatic.
A missing guard, a race condition, an assumption that does not hold in certain contexts.
Tiny things with big consequences.
You patch them carefully, test again and hope that the silent chain of events no longer appears.
A missing guard, a race condition, an assumption that does not hold in certain contexts.
Tiny things with big consequences.
You patch them carefully, test again and hope that the silent chain of events no longer appears.
When a user sends a video or a screenshot, things finally start to make sense.
You see the exact moment where the app hesitates or misbehaves.
Small clues that reveal where your mental model does not match reality.
You see the exact moment where the app hesitates or misbehaves.
Small clues that reveal where your mental model does not match reality.
November 24, 2025 at 5:24 PM
When a user sends a video or a screenshot, things finally start to make sense.
You see the exact moment where the app hesitates or misbehaves.
Small clues that reveal where your mental model does not match reality.
You see the exact moment where the app hesitates or misbehaves.
Small clues that reveal where your mental model does not match reality.
Most of the work happens outside the editor.
You read logs, compare edge cases, isolate conditions, search for patterns.
You remove possibilities one by one until only a few remain.
It is slow, sometimes frustrating, but it is the only reliable path.
You read logs, compare edge cases, isolate conditions, search for patterns.
You remove possibilities one by one until only a few remain.
It is slow, sometimes frustrating, but it is the only reliable path.
November 24, 2025 at 5:24 PM
Most of the work happens outside the editor.
You read logs, compare edge cases, isolate conditions, search for patterns.
You remove possibilities one by one until only a few remain.
It is slow, sometimes frustrating, but it is the only reliable path.
You read logs, compare edge cases, isolate conditions, search for patterns.
You remove possibilities one by one until only a few remain.
It is slow, sometimes frustrating, but it is the only reliable path.
Then you build hypotheses.
What could cause the behaviour
What part of the flow is fragile
Where could a silent failure hide
You treat the bug like a story with missing pages and try to guess the parts that are not written.
What could cause the behaviour
What part of the flow is fragile
Where could a silent failure hide
You treat the bug like a story with missing pages and try to guess the parts that are not written.
November 24, 2025 at 5:24 PM
Then you build hypotheses.
What could cause the behaviour
What part of the flow is fragile
Where could a silent failure hide
You treat the bug like a story with missing pages and try to guess the parts that are not written.
What could cause the behaviour
What part of the flow is fragile
Where could a silent failure hide
You treat the bug like a story with missing pages and try to guess the parts that are not written.
The first step is always the same.
You accept that you know less than you think.
Recreating the user’s exact setup is almost impossible.
Different models, different OS versions, different data, different timing.
You start by admitting that your assumptions are probably wrong.
You accept that you know less than you think.
Recreating the user’s exact setup is almost impossible.
Different models, different OS versions, different data, different timing.
You start by admitting that your assumptions are probably wrong.
November 24, 2025 at 5:24 PM
The first step is always the same.
You accept that you know less than you think.
Recreating the user’s exact setup is almost impossible.
Different models, different OS versions, different data, different timing.
You start by admitting that your assumptions are probably wrong.
You accept that you know less than you think.
Recreating the user’s exact setup is almost impossible.
Different models, different OS versions, different data, different timing.
You start by admitting that your assumptions are probably wrong.