Books Bragging Building in Public Cycling Food for thought Interviews Journal Lucid Dreaming Mental Health Movies Open Goals Poetry Productivity Quotes Ranting Smart Keys Sustainability Travel Youper

Building in Public

  • The Vibe Life: Building Smart Keys for Mac

    , ,

    I didn’t realize I was about to enter the “vibe” industry when I started building Smart Keys. All I really wanted was a way to sound fluent in languages without doing the hard work. Let’s be real: learning languages is tough. So, I built an app that lets me fake my english fluency until I make it. Besides hating this reference, the thing here is that I’ll probably never make it. I may not be as fluent as I sound using tools like this.

    Still, Smart Keys did the job for me on my phone. It solved my laziness problem and gave me a sense of accomplishment. Translate a message, change to a more casual tone, proofread an email, all with one tap. Suddenly, I was hooked. This tiny app had me feeling like a fluent native speaker.

    Bringing the Vibe to My Desktop

    Once Smart Keys worked its magic on my phone, I thought: why not bring this vibe to my desktop? I wanted to cut down on the constant back-and-forth between tabs, the endless browser windows, and that infuriating cycle of copy-pasting. Small tasks, like checking email, sending a reply, or fixing a bug, don’t require much brainpower, but they drain your energy nonetheless.

    So, I created Smart Keys for Mac.

    The goal was simple: stay in my flow, move through tasks without jumping between apps, and avoid losing focus on anything. I wanted to type, hit a shortcut, and keep moving. Proofread, translate, fix code, all without leaving the current task.

    Simple. Efficient. Minimal.

    The Perils of a One-Code Solution

    Now, if you’ve ever tried to port an app from iOS to macOS, you’ll know it’s not as simple as change deployment target and calling it a day. That’s what I thought, but nope. The idea of maintaining one codebase sounded genius: keep it efficient, keep it synced, keep the maintenance low. But here’s the thing: macOS and iOS are like distant cousins. They share some traits but are entirely different creatures.

    “If debugging is the process of removing software bugs, then programming must be the process of putting them in.”

    – Edsger Dijkstra

    “Two platforms, one codebase” sounds like a dream, but I quickly realized that you can’t just slap a mobile UI onto a desktop app and call it a day. The screen sizes, input methods, window management, all these small details had to be adjusted. It’s like trying to fit a square peg into a round hole, but making it work without losing the essence of what you built.

    Conditions for macOS and iOS, but also for device resolution on iPhone and iPad.

    The Fine Line Between Efficiency and Overload

    Incorporating macOS-specific optimizations wasn’t as simple as resizing windows. The app had to manage multiple displays, adjust for different screen sizes, and still feel fluid while taking advantage of the desktop’s power. Every change, every tweak, led to a cascade of other adjustments. Maintaining a single codebase was efficient in theory, but it created a lot of headaches along the way.

    I spent more time testing than I care to admit, making sure one small change didn’t break something somewhere else. But that’s the process. There’s no such thing as an easy app transition (yet).

    Selling a Quiet Product That Does a Lot

    Now that Smart Keys mostly works, the challenge has shifted. I’m not wrestling with bugs as much as I’m wrestling with words. Building a product that blends into your day is one thing. Explaining it without making it sound like a blender full of features is another.

    It rewrites. It translates. It fixes weird grammar and polishes sloppy code. All in the background, with shortcuts you barely notice. That’s the magic. And also the problem.

    It’s hard to pitch a tool that isn’t trying to impress you. It just wants to help and then get out of the way. Try to summarize it in one sentence and you either oversimplify or overcomplicate. Try to be specific and it starts to sound like five tools in a trench coat.

    “First, write the press release. Then, build the product.”

    – Not me

    So now I’m figuring out how to talk about it without killing the simplicity. Selling a quiet product in a world that rewards loud ones. Making clarity feel exciting without dressing it up too much.

    Still, every time I’m stuck rewriting copy for the tenth time, it’s right there. I hit a shortcut, smooth things out, and move on.

    Sure, half the time I’m fixing the thing I just built, but hey, at least I’ve got good shortcuts for the apology emails.

  • Store Conversion? More like Store Distraction.

    , , ,

    Apple’s polished and carefully curated Benchmark Metrics are an illusion, designed to impress on paper but often disconnected from real-world performance. In other words, BS.

    Apple lays out a glossy percentile system, letting you compare your app’s metrics to others in the same category. It shows if you’re brushing shoulders with top performers (the 75th percentile) or stuck somewhere near the bottom (the 25th percentile). On the surface, it sounds super handy, like a leaderboard in a video game. In reality, some reports can be misleading. Sure, it feels good when you see your app “performing as well as top apps,” until you realize some numbers can be skewed by ads, special promotions, and other wildcards that don’t reflect genuine traction.

    I discovered that the hard way while tinkering on Smart Keys, an AI-powered keyboard I’ve been building to help people (especially myself) type faster and smarter. I was feeling way too proud of myself as I rearranged screenshots, polished keywords, and declared I’d cracked the code. The numbers insisted I was beating the top apps by a mile. Then I realized I was clinging to a metric that was all style, zero substance.

    I obsessed over four data points, hoping my “genius” would unlock the secrets of the App Store. Here’s the quick breakdown, served with a side of humble pie.

    1. Store Conversion: The most BS of all

    I treated this like my personal high score, proudly pointing at it like it was proof I had the Midas touch. Turns out it’s mostly driven by ads, the brute force of a solid marketing push, and unpredictable factors like being featured on popular blogs.

    You can test every ASO tweak in the book, but nothing outdoes a well-funded campaign. That dose of reality bruised my ego, especially when I realized I’d been celebrating a metric that anyone with a decent ad budget could inflate.

    2. Proceeds per Paying User: Almost BS

    This one fooled me for a while. It’s like checking your salary and forgetting about rent. Sure, “Proceeds per Paying User” looks impressive at a glance, but it hides the reality of how much you spent to acquire those users. If each paying user costs you three times what they bring in, you’re basically throwing money into a bonfire.

    Nothing bursts your revenue bubble faster than realizing your lunch budget is leftover ramen packets because you blew all your cash on ads.

    3. Crashes: Gold

    This is where I got a much-needed wake-up call. Smart Keys had an onboarding crash bug that nearly drowned my starry-eyed dreams. On a small team, testing across all devices and iOS versions is no walk in the park, so the crash rate ended up being my loudest alarm. It let me catch the bug before a wave of 1-star reviews hit.

    I’d rather stub my toe in the dark than face that. Crashes might not look sexy on a dashboard, but they show you if your app is on fire before everyone runs for the exits.

    4. Retention (D1, D7, D28): Be patient

    This one’s a slow burn that checks if people actually come back for more. Early on, I’d glance at the retention numbers and assume folks would stick around forever.

    Then I got a reality check: trial periods, paywalls, or freemium strategies can skew these stats, and retention is a marathon, not a sprint. I’m still catching my breath, but at least I know if people keep showing up, I’m doing something right.

    The truth is, these metrics can make you feel important, but they don’t tell the whole story. I’ve been learning more from watching the folks at Every and other brave souls building in public. They share real stories about triumphs and ugly mistakes, ASO magic tricks, and it’s oddly comforting to see the raw, unfiltered process.

    I’m trying to do the same here with Smart Keys, focusing on real-world user feedback that directly shapes my updates and features. If you’re curious how all this no-BS talk translates into an actual product, give Smart Keys a try, or keep an eye on my #BuildingInPublic journey to see how it evolves.

    Is any of these metrics relevant to you? Which metric should I dive into next?

    Have a good week filled with no-BS insights.
    (っ-,-)つ𐂃

  • No-BS Friday Metrics: Store Conversion Rate

    , ,

    App Store gurus love to talk about ASO tricks and how to squeeze every bit of conversion juice from the app store. But what if I told you it doesn’t really matter?

    Smart Keys store conversion rate is over 50% while the best apps barely scrape 8%. So either I’m a wizard or this is a BS metric.

    We, app builders, love the idea that some ASO tweak will be the magic bullet. A better subtitle, the right screenshots, a catchy promo text. Sure, those things help a little, but I’m sorry to say that you may be spending your time on the wrong task, they won’t move the needle in a meaningful way.

    Then what? What actually happened in October that store conversion sky rocketed? What’s the big ASO secret?

    It’s a three-letter word: Ads. No ASO magic tricks, no growth hacks, no overcomplicated strategy. just Ads iterations that started working well.

    So is this store conversion rate relevant? not really. It looks good on a dashboard, to brag, but that’s about it. Focus on what actually drives growth, not vanity metrics that make you feel good but don’t pay the bills.

    That’s it for today. Next Friday, I’ll dive into retention, the real deal.

    Have a no-BS weekend. See ya. ✌️

  • Did Apple copy me?

    , ,

    As a non-native speaker, I relied heavily on Grammarly for years. I couldn’t write a simple text without its proofreading capabilities. Recently, though, I found myself turning to ChatGPT with a simple prompt: “proofread this.” It did a much better job, but the constant copy-pasting was a hassle. I tried various AI keyboards, but most were just Grammarly copycats, constantly nudging me about comma placements or suggesting rewrites because my message wasn’t clear. All I wanted was a tool that would handle this for me effortlessly.

    I even started counting the clicks it took to proofread a simple text, 21 clicks to be exact. Still, the result felt off, often using Portuguese text structures that didn’t quite fit.

    So, about two months ago, I decided to experiment with iOS Keyboard Extensions to build my own solution. I just wanted a single button on top of my keyboard to proofread my text. One click and bam, done. The feature itself was simple to build, the real challenge was creating a good keyboard. When you build a keyboard extension on iOS, you have to design the entire keyboard. That’s when I discovered KeyboardKit, an open-source project by Daniel Saidi, that saved me months of development.

    But in this space, there aren’t many competitive barriers to building keyboard apps, there are hundreds, if not thousands, of these apps available. Only a few make real money, earning millions per month, while the rest flood the App Store. I knew that without a hefty marketing budget, this would be a fun personal experiment that might lead to something else down the line.

    I was happy with my MVP, to me was better than Grammarly already, so I started adding more features: keys that could convert a text to a casual tone, shortening it, generating pickup lines, even creating a “speak like a tech mogul” key. 🤦, I went overboard and ended up with over 150 new keys on my keyboard.

    Last week, I launched it to some close friends and ESL students to get their feedback. The response was full of amazing ideas, but the keyboard experience and autocorrection still lag behind the native iOS keyboard.

    Then, I had a thought: when Apple inevitably launches their LLM, they’ll likely integrate a native writing tool. And when they do, it’s going to be a game changer, at least for someone like me. Fast forward, and here we are: iOS 18 will include a native proofreading tool across both desktop and mobile. One click, and bam, your text is proofread everywhere without any hassle.

    And that’s just one of the new features in iOS 18. If you’re eager to explore Apple Intelligence and other new tools, download the iOS 18 beta.

    But if you want to give Smart Keys a try, the second-best writing tool 🥸, download it here: https://smartkeys.so/

    That’s it, I’m left wondering, with barriers to entry lower than ever, what will separate leaders from the pack in AI tech?

  • SF2.LA: Part 1

    ,

    Diego from 2 months ago:

    “No-code platforms are BS.”

    Diego from today:

    “No-code platforms are mostly BS. Except one, which is now my new BFF. 😉”

    I once firmly believed that low/no-code platforms couldn’t create novel technologies. However, I had the opportunity to challenge this belief while developing a solution for a non-profit campaign.

    The goal was ambitious: to connect the Strava and DonorDrive APIs to boost AIDS/LifeCycle participants’ campaigns by automatically sharing their training efforts and helping with their fundraising goals. This was something I had already been doing manually for my campaign, and friends were curious about how they could do the same.

    After exploring various no/low-code platforms, I discovered FlutterFlow, which perfectly fit my needs. It offers a comprehensive Cloud IDE, encompassing UI, Design System, Database, Authentication, Frontend, Backend, Webhooks, Version Control and more.


    Initially, I struggled to grasp some concepts and could have had a better experience. However, the FlutterFlow community was incredibly supportive, and after four very long weekends, I had a solution ready for all 2500+ participants. It’s still a work in progress but is already assisting other AIDS/Lifecycle participants.

    I hope it will make a significant difference for the organizations behind the event.
    I’m immensely grateful for the support and feedback from the cycling and tech communities. Your encouragement has been pivotal in this journey. This project marks just the beginning. I now see these solutions as catalysts for change, inspiring more tech-driven initiatives for social causes.

    If you’re a participant (or thinking about becoming one), I’d love to hear your feedback and your experience using it: https://sf2.la/