# Emanuele Di Pietro > iOS & Web Developer and indie hacker building products, sharing lessons, and documenting the journey. ## Core Pages - [Homepage](https://www.emanueledipietro.com) - [Italian homepage](https://it.emanueledipietro.com) - [Blog](https://www.emanueledipietro.com/blog) - [Blog RSS feed](https://www.emanueledipietro.com/blog/feed.xml) - [Blog sitemap](https://www.emanueledipietro.com/blog/sitemap.xml) - [Sitemap](https://www.emanueledipietro.com/sitemap.xml) - [Sitemap index](https://www.emanueledipietro.com/sitemap-index.xml) ## Emanuele Di Pietro Blog > Essays by Emanuele Di Pietro on indie hacking, iOS and Swift, AI developer tools, SaaS launches, product building, and personal growth. Main topics: ai, ai-tools, app-development, build-in-public, career, developer-experience, entrepreneurship, failure, focus, freedom, indie-hacking, ios, lessons-learned, mental-health, openai, personal-growth, productivity, saas, self-awareness, swift, swiftui, technology ## Latest Blog Posts - [The App That Changed My Life in 1 Month: Remodex — The Codex for iOS](https://www.emanueledipietro.com/blog/how-i-built-remodex) (2026-04-26): The story of Remodex: from a side project called Phodex to shipping the first Codex iOS app on the AppStore in one night, and what I gained even though I knew it wouldn't last. - [I Stopped Listening to Music for a Week. Here's What Happened to My Brain](https://www.emanueledipietro.com/blog/no-music-week) (2026-02-24): For one week, I removed music from my daily routine to see what silence would do. The result was less mental fog, more presence, and unexpected creativity. - [I Built ManyLinks in 11 Days to Fix My Broken Bookmark System](https://www.emanueledipietro.com/blog/manylinks-launch-story) (2026-02-19): I was saving links everywhere and finding none of them when I needed them. So I built ManyLinks: an AI-powered app to save, organize, and rediscover links fast. - [Being a Developer in 2026: Drowning in FOMO](https://www.emanueledipietro.com/blog/developer-fomo-ai-tools-2026) (2026-01-29): New AI tools drop every day. Claude Code, Cowork, ClawdBot, Remotion, OpenCode... How do you keep up without burning out? - [My First SaaS Failed. Here's What I Learned (And Why I'm Making It Free)](https://www.emanueledipietro.com/blog/first-saas-failure-lessons) (2026-01-29): The story of DP's Templates: how I spent months building a SaaS that got zero users, what went wrong, and the lessons I learned from failure. - [9 iOS Apps in 2 Years: What I'd Do Differently](https://www.emanueledipietro.com/blog/9-ios-apps-2-years-lessons) (2026-01-28): Lessons learned building multiple iOS apps - from choosing native over cross-platform to mastering ASO and shipping MVPs faster. - [Losing My Job Was the Best Thing That Happened to Me](https://www.emanueledipietro.com/blog/losing-job-blessing-disguise) (2026-01-27): How losing my first job led to freedom, self-discovery, and the courage to build my own path in tech. ## High-Intent Questions This Site Answers - Who is Emanuele Di Pietro? - What is Emanuele Di Pietro building? - What has Emanuele Di Pietro written about iOS, Swift, indie hacking, SaaS, and AI developer tools? - What lessons has Emanuele Di Pietro learned while launching apps and SaaS products? ## Identity - https://x.com/emanueledpt - https://github.com/emanueledpt - https://linkedin.com/in/emanueledpt - https://youtube.com/@emanueledpt ## Full Blog Post Text ### The App That Changed My Life in 1 Month: Remodex — The Codex for iOS URL: https://www.emanueledipietro.com/blog/how-i-built-remodex Published: 2026-04-26 Updated: 2026-04-26 Description: The story of Remodex: from a side project called Phodex to shipping the first Codex iOS app on the AppStore in one night, and what I gained even though I knew it wouldn't last. ![Remodex](/ios/remodex.png) It started because I couldn't sit still without my Mac. Every time I left the desk, I felt this itch. There was always one more thing to ship, one more bug to fix, one more idea I wanted to prototype. But I was stuck waiting until I got home. I needed a way to keep coding from my phone. --- Then Claude rolled out **/remote-control**. That was exactly what I needed. I could keep building from anywhere, straight from my phone, talking to my agent like I was at my desk. So I went on X to see who was doing the same thing for Codex. That's when I found a post from [**@SIGKITTEN**](https://x.com/SIGKITTEN). He had built the primordial Codex iOS app in a few hours using the Codex App Server. Rough, early, but it worked. That was the spark. --- **The first version wasn't even called Remodex. It was Phodex.** Phodex was supposed to be a 24/7-without-mac app. VPS + Traefik + Docker + GitHub. A whole environment running in the cloud where you could code and send PRs straight from your phone, no Mac required. I was deep into building it. Then 2 weeks in, [**@ajambrosino**](https://x.com/ajambrosino) from OpenAI dropped a post leaking Remote Connections. I read it twice. It was clear what was coming: OpenAI was about to release something native and official. Their own iOS app for Codex. Just a matter of time. And honestly? That's the moment something flipped in my head. --- **That night I made a decision. And it had nothing to do with strategy.** It was March 8th. I didn't pivot because I was scared of getting steamrolled. I didn't pivot to "save the project." I pivoted because I thought it would be **really, really funny** to ship the Codex iOS app before OpenAI did. That was it. Not a business decision. Not a competitive move. A personal challenge, half meme, half for the story I'd get to tell one day. The kind of thing you do just so that years from now you can casually drop, *"yeah, I shipped the Codex iOS app before OpenAI did"* and watch people's reaction. Maybe tell my kids one day. Maybe just laugh about it with friends. So I scrapped Phodex. The cloud setup, the Docker pipelines, the GitHub integration. All of it. I decided to build the Codex iOS app instead. Just me, my Mac, and a deadline I set in my own head for the meme of it: **finish it in one night**. I posted about it on X around midnight. Then I started brainstorming and building with Codex. --- **Around 4am, it was done.** The first working version of Remodex. I closed the laptop, opened a stream of the F1 Grand Prix, and tried to come down from the build high. A few hours later [**@romainhuet**](https://x.com/romainhuet) followed up with kind words. That's when I realized this was actually going somewhere. --- **Working with the Codex App Server was a mix of "I love this" and "why is this so painful."** What I genuinely love about OpenAI is that they ship these tools and let us build on top with our own subscriptions. Open source primitives that actually work. But it wasn't so easy at first. - Getting the tool calls right - Keeping responses in the correct order - Parsing everything cleanly - Live updates that didn't break under load Every one of those was its own battle. Credit where it's due though: they recently listened to the feedback and made the Codex App Server a bit more responsive. But I figured it out. And what came out of it was something I was actually proud to ship. --- **Here's the part nobody likes to hear.** I took this challenge knowing exactly how it would end. It was always just a matter of time before OpenAI released their own version. I wasn't naive about it. I just decided **the journey was worth more than the destination**. Today, exactly 1 month after the first AppStore release, [**@ajambrosino**](https://x.com/ajambrosino) leaked that they're working on the official Codex mobile app. There it is. The success of Remodex is going to come to an end. I knew it. I built anyway. --- **But I try to look at it differently.** Because here's what I actually got out of it: - The eyes of many people inside OpenAI - Real conversations with their team - A compliment from [**@theo**](https://x.com/t3dotgg), including on the fact that it's open source - Roughly 4k new followers in 1-2 months Those are not small wins. Those are the kind of wins you can't buy and can't fake. You build something good, in public, and the right people notice. --- **Now I'm working on something new.** It's called [**dpcode.cc**](https://www.dpcode.cc/), a clone of T3Code with way more features and a better UI. And I've been thinking: what if I connect it back to Remodex? Expand Remodex beyond just Codex. Add Claude. Add OpenCode. Add Cursor. Make it the **remote control for any agent you want to use**, from anywhere, on your phone. That's still up in the air. But the idea is sitting there, getting louder every day. --- **The lesson I'm taking from all of this:** Don't wait for the perfect window to ship something. Don't refuse to build because a bigger company might do it later. They probably will. But if you build it first, in public, and you do it well, the doors that open along the way are worth more than the product itself. Remodex was never just about the app. It was about putting myself in rooms I had no business being in. **And it worked.** --- *I'm documenting the full journey on [X/Twitter](https://x.com/emanueledpt), including what I ship, what breaks, and what I learn along the way.* ### I Stopped Listening to Music for a Week. Here's What Happened to My Brain URL: https://www.emanueledipietro.com/blog/no-music-week Published: 2026-02-24 Updated: 2026-02-24 Description: For one week, I removed music from my daily routine to see what silence would do. The result was less mental fog, more presence, and unexpected creativity. I've always been a guy that listened to so much music. It was on from the moment I woke up. Working. Driving. Showering. Cooking. It didn't matter. There was always something playing. I told myself it was just a habit. That it helped me focus. That I liked the energy. But the truth? I used music as a way to **escape reality and silence my own thoughts**. And at some point, I couldn't ignore what that was doing to me. My brain felt foggy all the time. **Not tired. Not distracted. Just... foggy.** Like there was always a layer of noise between me and my own head. Melodies looping. Lyrics replacing my internal monologue. Constant stimulation that left zero room for silence, and zero room to actually think. So I decided to stop. --- **One week. No music.** The only exceptions: white noise, brown noise, and lo-fi. Nothing with lyrics. Nothing that could hijack my thoughts. --- **Day 1 was strange.** The moment I woke up, my hand moved toward my phone on autopilot. Open Spotify. Play something. I caught myself. Put the phone down. The silence felt louder than I expected. --- **The first two days were uncomfortable.** Without music, thoughts started surfacing. Old ones. Unprocessed ones. Stuff I hadn't given space to in months. It felt like living in a room with the TV always on, and someone finally turned it off. I replaced my morning Spotify ritual with just silence. Sometimes white noise or brown noise to ease into it. Nothing else. Sometimes I listened to podcasts or watched videos in the background of topics I was interested in. It wasn't comfortable. But I stayed with it. --- **Then something shifted around day 3.** I woke up and my head was clear. Not just quieter. **Actually clear.** Like a fog had lifted that I didn't even realize was there. And then ideas started coming on their own. Not forced. Not from staring at a blank page trying to think. Just showing up on their own, in the car, during a workout, in the shower. My brain finally had enough space to produce something. I drove in silence. Trained in silence. Worked in silence. And instead of feeling empty, it felt like being **present** for the first time in a while. --- **Here's what actually changed:** Mornings hit differently. Without Music as the first input of my day, my mind woke up on its own terms. **Slower. Cleaner. More mine.** Creativity came back uninvited. I wasn't looking for ideas. They just showed up. I became more aware of everything around me. Sounds, thoughts, moments I would've usually drowned out. --- **By the end of the week, something had permanently shifted.** I still let myself listen sometimes, in the evenings, as an actual choice. If a song got stuck in my head, I'd play it just to scratch the itch. Then stop. **No more endless autoplay.** No more using music as wallpaper for my brain. It went from something I couldn't function without, to something I choose when I genuinely want it. That's a completely different relationship. --- **This wasn't really about music.** It was about **learning to stop running from silence**. And discovering that the thoughts I'd been avoiding were actually worth having. ### I Built ManyLinks in 11 Days to Fix My Broken Bookmark System URL: https://www.emanueledipietro.com/blog/manylinks-launch-story Published: 2026-02-19 Updated: 2026-02-19 Description: I was saving links everywhere and finding none of them when I needed them. So I built ManyLinks: an AI-powered app to save, organize, and rediscover links fast. ![ManyLinks](/web/manylinks.png) I was saving 20+ links a day and finding almost none of them later. Articles, tools, GitHub repos, AI resources. I was dumping them into browser bookmarks, Notes, chats, and random docs. Then when I actually needed something, it was gone. So I built **ManyLinks**. ## The Problem My "save for later" system was chaos: - Bookmarks I never reopened - Links spread across too many apps - No reliable way to search everything in one place The main pain wasn't saving links. It was **rediscovering** them when it mattered. ## Why I Decided to Build It I couldn't find a simple tool that did all three things well: 1. Save any URL fast 2. Organize it automatically 3. Make it easy to find later So I started building my own solution in public. ## From Idea to Launch in 11 Days I shipped it quickly and iterated daily. ### Day 3: First real version - Basic UI working - Link ingestion in place - First folder flow implemented ### Day 4: Public feedback I shared it early and got direct feedback from my audience. That helped shape what mattered most in v1. I also asked people to vote on the domain. The winner was **manylinks.app**. ### Day 11: Launch-ready - Core product experience stable - Pricing and onboarding polished - Security and rate limits added - Product live for real users ## What ManyLinks Does ManyLinks is built around one promise: **stop losing useful links**. From the live app today: - **AI-powered categorization**: paste any URL, and AI extracts metadata, categorizes it, and writes a concise summary - **Folder-based organization**: keep links cleanly grouped and easy to manage - **Markdown export**: move your library into tools like Notion or Obsidian - **Full-text search**: search across titles, summaries, and tags to rediscover links instantly If you save lots of content to "read later," this is exactly what it's for. ## What I Learned Shipping This Fast ### 1. Build for your own daily pain first The feedback loop is much faster when you're the first power user. I used ManyLinks while building it, so priorities stayed obvious. ### 2. Building in public improves product decisions Public updates and quick feedback made the product better in days, not months. It also made launch less scary, because people were already following the journey. ### 3. Speed comes from focus, not rushing I didn't build everything. I built the core loop: **save -> auto-organize -> find again**. That single focus made the launch possible. ## Try ManyLinks ManyLinks is now live. If your bookmarks are a mess and your "saved links" never get reused, try it: **[manylinks.app](https://www.manylinks.app)** --- *I'm documenting the full build-in-public journey on [X/Twitter](https://x.com/emanueledpt), including what I ship, what breaks, and what I learn.* ### Being a Developer in 2026: Drowning in FOMO URL: https://www.emanueledipietro.com/blog/developer-fomo-ai-tools-2026 Published: 2026-01-29 Updated: 2026-01-29 Description: New AI tools drop every day. Claude Code, Cowork, ClawdBot, Remotion, OpenCode... How do you keep up without burning out? Being a developer in 2026 means you'll probably die of FOMO. Every single day, a new AI tool drops. Every week, someone launches "the next big thing" in developer productivity. And every month, you're left wondering: *Am I falling behind?* Here's just a sample of what's launched recently: - Claude Code - Claude Cowork - ClawdBot - Mac mini shortage (everyone's buying them for local AI) - Remotion - OpenCode **Honestly? I can't keep up anymore.** And I'm pretty sure I'm not alone. ## The Developer FOMO Cycle If you're a developer in 2026, your daily routine probably looks something like this: - **9:00 AM** — Wake up, check X/Twitter - **9:05 AM** — See 3 new AI tools launched overnight - **9:10 AM** — Feel anxiety about not having tried them yet - **9:15 AM** — Bookmark them "to check out later" - **9:20 AM** — Try to start actual work - **9:30 AM** — Someone posts about how [New Tool] saved them 10 hours - **9:35 AM** — Question all your tool choices - **9:40 AM** — Spend 2 hours researching if you should switch - **11:40 AM** — Finally start actual work Sound familiar? ## Why This Is Happening The explosion of AI developer tools in 2026 isn't random. Here's what's driving this madness: ### 1. **AI Is Eating Software Development** LLMs have gotten so good that they're fundamentally changing how we build software. We went from "AI can autocomplete my code" to "AI can build entire features" in less than 2 years. Every week brings new capabilities: - AI that writes tests - AI that reviews pull requests - AI that generates entire applications - AI that debugs production issues - AI that refactors legacy code ### 2. **The Barrier to Entry Is Zero** It's never been easier to launch a developer tool: - Wrap an LLM API with a nice interface - Add some prompting magic - Ship it with a landing page - Launch on Product Hunt and X Result? Hundreds of new tools every month, each promising to "10x your productivity." ### 3. **Genuine Innovation Is Happening** Here's the thing: **some of these tools are actually game-changing.** Claude Code legitimately changed how I build projects. GitHub Copilot saved me countless hours. Cursor made me rethink my entire IDE setup. So you can't just ignore all the new tools, because buried in the noise are genuine breakthroughs. ## The Tools Everyone's Talking About Let me break down what's causing the FOMO right now: ### Claude Code Anthropic's CLI tool for agentic coding. It's like having a senior developer pair with you in the terminal. Genuinely useful, but there's a learning curve. ### Claude Cowork The desktop version for non-developers, but developers are using it too for file management and automation. Another thing to learn. ### ClawdBot Yet another AI coding assistant. Is it better than the 47 others? Who knows, but everyone's talking about it. ### Mac Mini "Shortage" Everyone's buying Mac minis to run local LLMs. If you don't have one, are you even a serious developer anymore? (Joking, but the FOMO is real.) ### Remotion Programmatic video generation. Looks incredible. Do I need it? Probably not. Am I worried I'm missing out? Absolutely. ### OpenCode An open-source alternative to [something]. I bookmarked it 3 days ago and haven't looked at it since. ## The Real Cost of FOMO This constant barrage of new tools has real consequences: ### 1. **Analysis Paralysis** You spend more time researching tools than actually building. Every decision becomes a question of "is this the optimal choice?" ### 2. **Productivity Theater** You're constantly switching tools, learning new workflows, configuring new setups. You feel busy, but you're not actually shipping. ### 3. **Burnout** The feeling that you're always behind, always missing out, always need to learn the next thing. It's exhausting. ### 4. **Imposter Syndrome** Everyone else seems to be effortlessly using all these new tools. You're struggling to keep up with one. You must be a bad developer, right? (Spoiler: No, you're not.) ## How I'm Dealing with It After months of FOMO-induced anxiety, here's what's working for me: ### Set Clear Criteria for New Tools I only seriously evaluate a tool if it: - ✅ Solves a problem I actually have (not a hypothetical one) - ✅ Has clear evidence of working (real user testimonials, not just marketing) - ✅ Can be tested in < 30 minutes - ✅ Doesn't require a massive workflow change Everything else gets ignored. ### Embrace "Good Enough" You don't need the optimal tool for everything. You need tools that: - Work reliably - You understand well - Let you ship products Your current stack is probably fine. Really. ### Schedule Tool Exploration Instead of context-switching every time something new drops: - Bookmark interesting tools - Have a dedicated "tool exploration" time once per month - Batch evaluate multiple tools at once - Make deliberate decisions ### Remember What Actually Matters At the end of the day, what matters is: - **Shipping products** that people use - **Solving real problems** for real users - **Learning and growing** as a developer - **Maintaining your mental health** Nobody cares if you used Claude Code vs Cursor vs raw Vim. They care if your product works. ## Key Takeaways Here's what I want you to remember: 1. **You can't keep up with everything** - And that's okay. Nobody can. 2. **Most tools are 10% better, not 10x better** - The truly revolutionary tools are rare. Most are incremental improvements. 3. **Your tools don't define you** - You're not a better developer because you use the newest AI assistant. 4. **Shipping beats optimization** - Building with "good enough" tools is better than endlessly searching for perfect ones. 5. **FOMO is a feature, not a bug** - The tools want you to feel like you're missing out. Don't let marketing dictate your emotions. ## Permission to Opt Out Here's something nobody says enough: **You have permission to not care.** You don't need to try every new AI tool. You don't need to have an opinion on every launch. You don't need to be early to everything. You can use the same tools you used last year, focus on building great products, and be a perfectly successful developer. The best tool is the one you actually use to ship products. Everything else is noise. ## Moving Forward My personal strategy for 2026: - **Focus on fundamentals** - Get really good at the tools I already use - **Ship more, optimize less** - Build products, not perfect workflows - **Batch learning** - Explore new tools once per month, not once per day - **Trust my instincts** - If something genuinely seems game-changing, I'll know Will I miss out on some cool tools? Probably. Will it matter? Probably not. ## Final Thought The FOMO is real, and it's exhausting. But remember: **the goal isn't to use every tool. The goal is to build great things.** So next time you see a shiny new AI tool launch, ask yourself: - Do I have a problem this solves? - Is it significantly better than what I have? - Is now the right time to learn it? If the answer to any of these is "no," close the tab and get back to building. Your future self will thank you. --- *Trying to stay sane in the age of AI tools. Follow along on [X/Twitter](https://x.com/emanueledpt) where I share my journey as an indie developer.* ### My First SaaS Failed. Here's What I Learned (And Why I'm Making It Free) URL: https://www.emanueledipietro.com/blog/first-saas-failure-lessons Published: 2026-01-29 Updated: 2026-01-29 Description: The story of DP's Templates: how I spent months building a SaaS that got zero users, what went wrong, and the lessons I learned from failure. My first SaaS failed. Completely. Zero users. After months of work, Supabase shut it down due to inactivity. But instead of letting it die quietly, I decided to make it free and share what I learned. ## What I Built: DP's Templates **DP's Templates** was supposed to be my first successful SaaS product—a modern Next.js component library that would help developers ship faster. The offering was solid: - **40+ pre-made UI components** - Buttons, forms, navigation, cards, you name it - **4+ complete landing page templates** - Ready-to-deploy designs for different use cases - **Built with modern tech** - Next.js, TypeScript, Tailwind CSS - **Developer-friendly** - Clean code, easy to customize On paper, it looked great. I spent months designing components, writing documentation, setting up the infrastructure with Supabase for authentication and payments. Everything was polished and ready to go. ## The Reality Check: Zero Users Here's the hard truth: **I got no users.** Not "a few users," not "some traction." Literally zero paying customers. The silence was deafening. I'd launch on Twitter, post in communities, try to generate interest. Nothing. The landing page got some visitors, but they'd bounce immediately. No signups, no trials, no feedback. Eventually, Supabase's automated system did what it's designed to do: it shut down inactive projects to free up resources. And just like that, my first SaaS was dead. ### What Went Wrong Looking back, I can now see the mistakes clearly. Here's where I went wrong: **1. I Built in a Vacuum** - Never validated the idea with potential users - Assumed developers needed "yet another component library" - Didn't talk to a single potential customer before building **2. The Market Was Oversaturated** - shadcn/ui was already dominating - Dozens of other component libraries existed - I had no unique differentiator or compelling reason to switch **3. No Distribution Strategy** - "If you build it, they will come" doesn't work - I had no audience, no marketing plan, no growth strategy - A few tweets and posts weren't enough **4. Wrong Problem, Wrong Solution** - I built what I thought was cool, not what people needed - The "problem" I was solving wasn't painful enough - Developers already had free alternatives that worked great ## The Decision: Make It Free After the initial disappointment wore off, I had a choice to make: 1. Let it die quietly and move on 2. Try to revive it as a paid product 3. Make it completely free I chose option 3. Why? Because even though it failed as a business, the work itself isn't worthless. Those 40+ components and landing page templates could still help someone build faster. And more importantly, **I could turn a private failure into a public lesson.** ### What You Get (For Free) If you want to use DP's Templates, it's all yours: - ✅ All 40+ UI components - ✅ All 4 landing page templates - ✅ Full source code access - ✅ Documentation and examples - ✅ No attribution required *[Link to project repository would go here]* ## Key Lessons from Failure Failure is only truly failure if you don't learn from it. Here's what this experience taught me: ### 1. **Validation Before Building** The biggest mistake was building without validating demand. Next time, I'll: - Talk to at least 10 potential customers before writing a single line of code - Create a landing page and gauge interest before building - Look for signs of real pain points, not just nice-to-haves ### 2. **Distribution > Product** A great product without distribution is worthless. The formula is simple: > **Great Product + No Distribution = Zero Users** > **Decent Product + Great Distribution = Success** Next time, I'll build an audience first, then build a product for that audience. ### 3. **Differentiation Is Everything** "Better features" isn't a differentiator if 10 other products already exist. I needed to answer: - Why would someone switch from their current solution? - What can I offer that literally nobody else can? - Is this 10x better, or just 10% better? ### 4. **Start Smaller** Spending months on a v1 without user feedback is a recipe for failure. Better approach: - Build the minimum viable product in a week - Get it in front of users immediately - Iterate based on real feedback - Only invest more time once you have traction ### 5. **Market Timing Matters** Even a good idea can fail if the market is already saturated or if you're too early/late. I entered a crowded market with no clear advantage. That's like opening a coffee shop next to Starbucks and hoping for the best. ## Moving Forward Here's what I'm doing differently with my next projects: **✓ Talk to users first** - At least 10 conversations before building **✓ Build an audience** - Growing my Twitter/X presence and email list **✓ Ship smaller, faster** - MVPs in days, not months **✓ Find underserved niches** - Look for gaps, not crowded markets **✓ Distribution plan from day 1** - Know how I'll reach users before I start building ## Why Share This? I'm sharing this failure publicly for a few reasons: 1. **Someone else might avoid the same mistakes** - If my experience helps even one person validate before building, it's worth it 2. **Normalize failure in public** - Too many people only share their wins; failures are where the real learning happens 3. **Turn a loss into a win** - The SaaS failed, but the lessons are valuable ## Your Takeaway If you're building a SaaS or thinking about it, here's what I want you to remember: > **Validate first. Build second. Launch often. Iterate always.** Don't spend months in your cave building the perfect product. Get something basic in front of users as fast as possible, and let their feedback guide you. And if it fails? Learn from it, share the lessons, and move on to the next thing. Every failure gets you closer to success—if you extract the lessons. ## DP's Templates Is Now Free Forever I spent months building it. You can benefit from it in minutes. That feels like a win to me. If you want to ship your next landing page faster, grab the templates. If you're building a SaaS, learn from my mistakes. Either way, I hope this helps you move forward. --- *Building in public and learning from failures. Follow my journey on [X/Twitter](https://x.com/emanueledpt) where I share what I'm working on and what I'm learning.* ### 9 iOS Apps in 2 Years: What I'd Do Differently URL: https://www.emanueledipietro.com/blog/9-ios-apps-2-years-lessons Published: 2026-01-28 Updated: 2026-01-28 Description: Lessons learned building multiple iOS apps - from choosing native over cross-platform to mastering ASO and shipping MVPs faster. I've built **9 iOS apps in 2 years**. It's been a wild ride of successes, failures, and hard-won lessons. Looking back, there are several things I'd do differently to accelerate growth, improve quality, and ship faster. Here's what I learned—and what I'd change if I started over today. 9 iOS apps in 2 years - lessons learned ## 1. Go Native iOS Instead of Cross-Platform ### The Mistake Early on, I flirted with cross-platform solutions. The temptation is strong: write once, deploy everywhere. But the reality is painful. ### The Reality **iOS users spend 2.5x more per install** ($2.12 vs $0.85) and the development experience is infinitely better when you're native. When you use a cross-platform framework, you're always fighting compromises: - Subpar UI that doesn't feel native - Performance hits - Bloated app size - Missing latest iOS features - Debugging nightmares ### The Solution **Go all-in on native Swift/SwiftUI.** Yes, you miss the Android market. But: - ✅ Better monetization potential ($2.5x per user) - ✅ Apple ecosystem is unified and predictable - ✅ Access to latest APIs immediately - ✅ App Store favors native apps - ✅ Development is genuinely more enjoyable The opportunity cost of chasing cross-platform is higher than the upside. --- ## 2. Use SwiftUI + Latest APIs (Not UIKit) ### The Mistake UIKit is powerful, but it's like learning to drive with a manual transmission when automatics exist. ### Why SwiftUI Wins SwiftUI + the latest APIs = **faster development + modern UX**: - Declarative syntax (write less, understand more) - Live preview (instant feedback) - Automatic dark mode support - SwiftUI modifiers > UIKit stack views - Built for modern iOS features ### The Catch You need to target recent iOS versions (iOS 15+). But honestly? That's fine. Your users will update, and you'll ship faster. ### Action Item If you're starting a new project today, go SwiftUI. Full stop. --- ## 3. Use SwiftData for Local Storage (Not Over-engineered Backend) ### The Problem Early apps, I over-engineered the backend. Database syncing, cloud services, complex APIs. Overkill for 90% of use cases. ### The Solution **SwiftData is a game-changer.** SwiftData gives you: - ✅ Local persistent storage (fast) - ✅ Automatic migration - ✅ CloudKit integration is easy too - ✅ Query syntax that's intuitive - ✅ Zero backend complexity for simple apps **When to add a backend:** Only when you actually need multi-device sync or server-side logic. Not before. Most apps don't need it. Shipping a working local app beats shipping nothing while you architect the "perfect" backend. --- ## 4. Study ASO (App Store Optimization) ### The Mistake I treated the App Store like a search engine. Write good code, ship it, wait for downloads. Naive. ### The Reality **App Store Optimization (ASO) is real, and it matters.** Better keywords = better discoverability = more downloads. More downloads = better algorithm placement. ### What to Optimize - **App name & subtitle** - Keywords matter - **Keywords field** - Research competitor keywords - **Icon & screenshots** - First impression is everything - **Description** - Conversions matter - **Ratings & reviews** - Quality signals ### The Compound Effect An app optimized for ASO gets 3-5x more organic traffic than an ignored app with the same features. Spend time here. It's multiplied by the millions of potential users. --- ## 5. Ship Working MVPs (Don't Perfectionism-Block) ### The Mistake Waiting for 100% feature completeness before launch. Polishing endlessly. Perfectionism paralysis. ### The Truth **One fully-working feature beats 10 half-baked ones.** Apple review is strict but fair. A focused, polished MVP: - ✅ Ships faster (months not years) - ✅ Gets user feedback early - ✅ Builds momentum - ✅ Easier to iterate ### The Psychology Shipping makes you feel good. It proves you can finish. Half-built projects drain motivation. **Ship an MVP. Get it live. Then iterate.** You'll improve faster with real users than with your own guesses. --- ## 6. Market on TikTok (Not Just App Store) ### The Mistake Relying 100% on App Store organic search traffic. It's a lottery. ### The Opportunity **Short-form video is absurdly effective for apps.** TikTok demos convert better than any paid ads because: - ✅ Authentic (not polished ads) - ✅ Shows actual functionality - ✅ Viral potential (low cost, high reach) - ✅ Algorithm favors engaging content - ✅ iOS users are there ### What Works 15-30 second clips showing: - A problem the app solves - How to use it - The satisfying payoff ### Why I Missed This It feels unsophisticated compared to "App Store SEO." But TikTok drives installs, period. --- ## Putting It All Together If I rewound 2 years and started fresh: 1. **Native Swift + SwiftUI** from day one 2. **SwiftData** for persistence (no backend until needed) 3. **Ship the MVP** in 4-6 weeks (not 6 months) 4. **ASO research** before naming the app 5. **TikTok marketing** immediately after launch 6. **Iterate based on user feedback**, not guesses --- ## The Meta Lesson **iOS development is different from web dev, but easier than you think.** It's not harder—it's just different. Use AI, learn as you build, and don't overthink it. > If I did it, you can too. 😊 The barrier to entry has never been lower. SwiftUI is beginner-friendly. Swift is beautiful. The App Store reaches billions of potential users. The only thing stopping you is shipping. --- ## What's Next? If you're curious about iOS development: - Start with [SwiftUI tutorials](https://developer.apple.com/tutorials/swiftui) - Build something small (a calculator, a habit tracker) - Ship it to the App Store (the review process is educational) - Market on TikTok - Iterate based on feedback The best time to build 9 iOS apps was 2 years ago. The second best time is now. Let's build something. 🚀 ### Losing My Job Was the Best Thing That Happened to Me URL: https://www.emanueledipietro.com/blog/losing-job-blessing-disguise Published: 2026-01-27 Updated: 2026-01-27 Description: How losing my first job led to freedom, self-discovery, and the courage to build my own path in tech. Two months ago, I lost my first job. At that moment, it felt like the end of the world. But looking back now, I realize it was actually a blessing in disguise—one that changed my entire perspective on work, life, and what I'm truly capable of. ## The Initial Shock When I first got the news, I was shattered. The immediate panic set in: **no stable income**, bills to pay, uncertainty about the future. For anyone who's been through this, you know that sinking feeling in your stomach when your sense of security suddenly vanishes. The rational part of my brain kept listing all the problems: - What will I tell my family? - Will I be able to find another job quickly? - Am I a failure? But there was another voice, quieter at first, that whispered something different. ## The Hidden Cost of "Stability" While I was worrying about losing my stable income, I started to realize what I was actually gaining. No more waking up at 8am to sit at a desk for 8 hours, working on projects that felt meaningless. No more pretending to be busy when I knew I was meant for more. **That job was draining me.** My mental and physical health were steadily decreasing. I was trading my time, energy, and creativity for a paycheck—and it wasn't a fair trade. The truth is, I knew deep down that I was meant for more. I had ideas, projects I wanted to build, skills I wanted to develop. But the 9-5 grind left me with no energy or motivation to pursue them. ## The Blessing in Disguise With time and reflection, I came to a powerful realization: **losing that job was one of the best things that could have happened to me.** It forced me to confront a truth I'd been avoiding: I don't want a traditional 9-5 anymore. I want the freedom to work on projects I care about, to set my own schedule, to take risks and learn from them. ### Key Realizations Here's what I learned during this transition: - **Security is often an illusion** - That "stable" job could disappear at any moment, as I learned firsthand - **Time is more valuable than money** - Once I had my time back, I could invest it in building real value - **Growth happens outside comfort zones** - Being forced out of my comfort zone accelerated my personal and professional development - **Fear is temporary, regret is permanent** - I'd rather try and fail than wonder "what if" for the rest of my life ## From Panic to Purpose Sometimes when something bad happens, we panic. We think it's over. We catastrophize and imagine the worst possible outcomes. **Trust me: most of the time, it isn't the end.** It's actually the start of something new and bigger. The job loss that felt like a catastrophe became a catalyst. Without the constraints of a traditional job, I started: - Building projects I actually care about - Learning new technologies at my own pace - Connecting with other indie hackers and entrepreneurs - Taking control of my own career trajectory ## What I'd Tell My Past Self If I could go back two months and talk to the version of me who just lost his job, here's what I'd say: > "This feels terrible right now, and that's okay. But this is your chance. Your chance to bet on yourself, to build something meaningful, to live on your own terms. Don't waste it by rushing back to another job that will drain you the same way. Use this time wisely." ## Moving Forward I'm not going to pretend it's all sunshine and rainbows. Building your own path is hard. There are still days of uncertainty, financial stress, and self-doubt. But there's something incredibly powerful about waking up each day and working on something you genuinely care about. About knowing that your success or failure is entirely in your own hands. ### Key Takeaways If you're going through something similar right now, here's what I want you to remember: 1. **The panic is temporary** - Give yourself time to process, but don't let fear paralyze you 2. **Reframe the situation** - What looks like a setback might actually be an opportunity in disguise 3. **Take action quickly** - Don't let uncertainty turn into paralysis; start building something new 4. **Trust the process** - Sometimes you need to lose something to gain something better ## Keep Pushing Forward Whatever challenge you're facing right now—whether it's a job loss, a failed project, or any other setback—remember this: **it's probably not the end. It's just the start of something new and bigger.** The key is to keep pushing forward, even when you can't see the full picture yet. Keep building, keep learning, keep betting on yourself. Your best work is still ahead of you. --- *Have you experienced a similar turning point in your career? I'd love to hear your story. Connect with me on [X/Twitter](https://x.com/emanueledpt) and let's talk about it.*