iiinova — where your digital self keeps evolving

It immediately changes how you look at your UI decisions. And its totally worth trying if your team has never done it before.

010

A lot of “good accessibility” is just thoughtful product design. One thing we started doing internally after that was testing features with: - larger text enabled - reduced motion enabled - VoiceOver turned on - darkMode enable etc.

121

And the interesting part is that accessibility improvements rarely make an app worse. Usually the opposite happens. The interface becomes cleaner. Navigation becomes simpler. Content becomes easier to understand.

110

Nothing catastrophic. The app still technically worked. But the experience clearly wasn’t designed for everyone. I think a lot of developers underestimate how many people deal with these issues every single day.

100

A few years ago I spent some time using one of our apps with accessibility settings turned on and honestly it was uncomfortable to watch. A few screens became difficult to read with larger text sizes. Some buttons were easy to miss. VoiceOver highlighted things we forgot to label properly.

100

I have worked on apps for years and accessibility is one of those things I barely thought about in the beginning. You hear about it. You know it matters. But most teams are busy shipping features and fixing bugs, so it quietly gets pushed aside. 🧵

120

By the time i realized i could do that the post was already submitted and bsky wont let me edit the post. too bad.

100

It immediately changes how you look at your UI decisions. And its totally worth trying if your team has never done it before.

000

100

100

200

100

If you’ve dealt with painful mobile architecture decisions before, repost this for your team. Also curious: What’s the worst architecture anti-pattern you’ve had to clean up?

000

Good architecture isn’t about over-engineering. It’s about protecting future development speed. The best teams don’t just optimize for shipping fast once. They optimize for shipping fast repeatedly.

100

The interesting part is that none of these issues hurt immediately. That’s why teams ignore them early on. The app still ships. Everything feels “fine.” Until development velocity suddenly disappears.

100

What works better: API models become domain models, and domain models power the UI. That separation gives flexibility. Backend changes become manageable. New APIs become easier to integrate. UI becomes more stable long term.

110

The third mistake is tight API coupling. Backend changes one response field… …and suddenly multiple mobile screens break. Why? Because raw API models are directly connected to the UI layer.

100

One architecture shift changes everything: Instead of: API directly powering the UI Use: API feeds local database, and local database feeds the UI. This makes apps: feel faster work better on weak networks recover gracefully reduce loading states

100

The second mistake is skipping offline handling completely. A lot of apps still assume users always have stable internet. Real users don’t. That’s why so many apps feel unreliable in daily use.

100

The fix: Keep ViewModels focused on presentation state. Move business logic into: services repositories use cases The moment responsibilities are separated properly: testing gets easier onboarding gets easier features stop breaking unrelated screens

100

The first one is the “God ViewModel.” One ViewModel handles: networking caching analytics validation navigation UI state business logic It feels productive early on. Then nobody wants to touch the file 6 months later.

100

Most early-stage mobile apps don’t become hard to maintain because the team is bad. They become hard to maintain because small “fast” architecture decisions quietly turn into long-term friction. I keep seeing the same 3 mistakes in mobile codebases 🧵

100

AI should increase human output. Not remove humans from the economy. Repost if you think more founders need to hear this. And curious: Will AI create more jobs than it destroys over the next decade?

000

The companies that win won’t be the ones that removed humans fastest. They’ll be the ones that made humans dramatically more powerful.

100

Even Goldman Sachs estimated AI could impact hundreds of millions of jobs globally. And the IMF warned AI may affect nearly 40% of jobs worldwide. This is a civilization-level shift.

100

That means: faster execution smaller high-performing teams lower burnout more innovation higher profit margins WITHOUT removing people from the economy.

100

Instead of: 1 employee → replaced by AI The future is: 1 employee + AI → 5x output That changes everything.

100

The smartest companies won’t replace humans with AI. They’ll build: Human + AI systems. That’s the unlock.

100

The biggest misconception: AI replacing jobs ≠ automatic economic growth. If millions lose income: fewer people buy products fewer subscriptions renew fewer businesses grow The loop breaks.

100

MIT researchers and economists have warned about this for years: Automation mainly benefits capital owners when businesses don’t reinvest gains into workers.

100

History already showed us what happens when productivity grows… …but wages don’t. We get: weaker consumer spending higher inequality unstable economies slower long-term growth

100

Most companies are treating AI like a salary-cutting machine. That’s the mistake. You still need customers with money to buy what you sell.

100