observedby

The Workflows I Actually Ship With

Sun, 27 Apr 2025 00:00:00 GMT

I know, you don’t stop seeing tweets, posts, and videos about how AI is changing everything. Some are cataclysmic, predicting our replacement by the next shiny model, while others, more realistically, share what’s new and how you can leverage it.

But after all the noise, it can feel too abstract, especially if you aren’t actively trying out AI in your day-to-day coding. It’s easy to dismiss the hype when you’re focused on shipping features and fixing bugs.

The Reality Gap Between AI Hype and Developer Experience

Let’s be honest, if you haven’t actively experimented with AI coding tools in your daily workflow, the endless stream of tweets and LinkedIn posts probably feels disconnected from your reality. The gap between “AI will replace all developers by next Tuesday” and “I just need to fix this bug before standup” is massive.

I’m deeply immersed in the world of AI, constantly experimenting with different tools and approaches. Even so, I find it challenging to convey to friends and colleagues who haven’t taken the plunge just how profoundly AI is already changing our work lives in practical ways. They see the demos and the sales pitches, but those perfect scenarios rarely reflect the messy reality of professional development. That disconnect is precisely why I decided to write this post and document my journey, not the highlight reel of perfect interactions, but the evolving, sometimes frustrating, ultimately transformative process of integrating AI into real-world development work.

The Evolution of an AI-Augmented Workflow

My journey with AI in coding began about a year ago. I took on a complex project I was obsessed with, which became my testing ground. You can read the story about the project and its early learnings here.

So, let’s get to the goodies: how did I start using AI, and how has that evolved over the past year?

From Quick Wins to Full Partnership

Initially, my use cases were very specific. I focused on implementing simple UI components or trying to one-shot small, self-contained features. For instance, I implemented a fully functional small paywall blocking my app’s features for unsubscribed users in about a minute.

Sure, it wasn’t the most complex piece of code. Building it manually, however, would likely have taken me around 30 minutes involving fiddling with state, styling, and logic. Seeing it come together so quickly made it clear this was already a game changer, freeing up valuable time and mental energy for more complex challenges.

Over months, my usage patterns evolved significantly. What started as targeted assistance with isolated components gradually transformed into a comprehensive development partnership.

Building Postr: Prompting an App into Existence

At this point, I had spent months developing a complex app, using AI primarily for minor yet relevant tasks. That’s when I decided to shift gears and implement a more straightforward app, one that would not only deliver value using AI but also be almost entirely prompted into existence.

This app is Postr.

The idea behind Postr was simple: empower people outside the AI bubble to train AI Assistants capable of writing social media posts in any desired style. Users could upload screenshots of posts they admire, and the AI would learn the nuances to replicate that style.

The development process for Postr looked like this:

AI Assistant: Cursor with the Claude Sonnet 3.5 model. In my experience, it outperforms OpenAI models, especially for native iOS codebases.
Context: Indexing relevant documentation web pages directly into Cursor.
Guidance: Using a great set of native iOS Cursor rules from Josh Pigford found here.
Design Input: Screenshots of Figma designs my friend Bruno had created for another project.

After about two months of prompting in my spare time, I had a remarkably polished version of the app ready. Virtually everything, from the core features to the RevenueCat integration, subscription state management, and paywalls, was implemented through prompting.

The MVP launch went surprisingly well. I gained 100 users in the first month, and even after 3 months (despite me abandoning further development), 24 recurring users remained. I decided to halt work on Postr because conversations with those initial users revealed a need for a pivot to truly unlock paid conversion. I’m currently working on that pivot, and you’ll hear more about it soon. However, the specific outcomes aren’t the main focus here.

Beyond Code: AI as a Lifeline in Hectic Times

The crucial point is the context surrounding the Postr launch. I had just moved to a new country, was leading significant projects at my day job, and my father was undergoing surgery. Life was hectic.

What I’m trying to emphasize is that without AI-assisted coding, Postr simply wouldn’t exist. It would have been another exciting idea I tinkered with, maybe integrated a few APIs for, and then inevitably relegated to the side project graveyard. I know many of you can relate to that feeling!

So, let’s recap the evidence presented so far. AI enabled me to:

Save significant time by having components fully implemented in a single shot.
Code an entire, real-world user-facing application in just two months, dedicating only a few hours each week.
Implement, polish, and even create design assets, making my apps look presentable with a fraction of the typical design effort.

Still think this is all just hype? Hold my beer.

Tackling New Frontiers: AI for Multiplatform Development

I have more examples. Shortly after launching Postr and gathering user feedback, I began working on a new project to address the insights I’d gained. This new project came with expanded requirements, the most critical being native multiplatform support (iOS and macOS).

Here’s the challenge: despite years of iOS development, I had never shipped a macOS app. Bootstrapping a project to support macOS natively, especially using SwiftUI from the ground up (my usual approach involved UIKit with embedded SwiftUI), felt daunting. While not overly complex, setting up authentication, a local database, API communication, and a basic, structured home screen for both platforms represented a substantial amount of tedious work.

Normally, this bootstrap phase would take considerable time. Using AI, I accomplished it in a single day.

My technique involved creating a folder named LLMReferences within the project. I filled this folder with relevant code snippets: examples from my previous projects, code from GitHub repositories I admired for their multiplatform handling, and even source code from dependencies (since Swift Package Manager dependencies aren’t directly indexable by Cursor within the project directory).

Below is one of the prompts I used to get the multiplatform structure working:

And here’s a visual comparison: the original ComposerScreen.swift from an iOS reference versus the basic HomeView.swift generated for the macOS target after the prompt:

iOS Implementation Example

macOS Implementation Example

Again, the result isn’t groundbreakingly complex or visually stunning. Yet, within a couple of hours, I had a functional, native multiplatform app bootstrapped according to my preferred best practices, looking decent enough to start iterating on the core features.

Specialists vs. Generalists: Where Does AI Fit In?

There’s a long-standing, sometimes heated discussion in the software development community: should you laser-focus on becoming a deep specialist or cultivate a broader skillset as a generalist? I’ve seen passionate arguments on both sides throughout my career. Honestly, I never strongly picked a side, my philosophy has always been that if you work hard and deliver value, there’s a place for you.

However, I always leaned towards the specialist path. An old friend, also an iOS developer, used to say there are so many APIs within the iOS SDK alone that we probably couldn’t master it all even after ten dedicated years, especially since it’s constantly evolving. That line of thought resonated with me. I felt I could provide more value to clients and employers by deeply specializing, and that’s the path I took.

It worked incredibly well, and I’m proud of where that dedication led me. But after about ten years, a subtle feeling started creeping in, a kind of professional FOMO. “What if I had learned more about backend development or modern frontend web technologies?” So much exciting innovation was happening elsewhere, and I felt like I might be missing out.

Exploring the Unknown

Well, that FOMO largely evaporated with the rise of AI-assisted coding. Recently, I decided to tackle my first significant web project in a very long time: the very website you might be reading this on right now (https://www.doubleslitapps.com/).

It’s a static Next.js site using MDX for the blog. Could I have built this before AI tools became prevalent? Technically, yes. I’d even considered it many times. But I knew achieving the level of polish it has now would have taken far longer than the few focused hours AI assistance allowed. That knowledge was a barrier, I simply hadn’t done it before because the time investment seemed too high compared to the potential return.

My time outside of my day job is limited, just like yours probably is. I have to be deliberate about what I choose to learn or experiment with. Building a static blog website, while useful, wouldn’t typically have topped my priority list unless I could create something high-quality very quickly. And that is one of the biggest powers of AI: it lowers the activation energy, enabling you to actually do the things you previously only thought about.

Knowledge Momentum Keeper

AI isn’t just an enabler, it’s also a fantastic momentum partner. The feeling is surprisingly similar to having a co-founder when I was running a startup. You see the value accumulating with each step, which motivates you to push further.

After shipping this Next.js site, I thought: why not offload the potentially long-running AI calls in my native app to a simple backend? It shouldn’t be too complicated, right?

And indeed, it wasn’t. Over the next weekend, I managed to:

Design and implement a secure file upload system using a private Cloudflare R2 bucket.
Set up a workflow involving a queue of workers that could: validate a user’s Firebase authentication token, upload the file to the private R2 bucket, generate a signed URL for temporary access, store the relevant information in a Firestore document, and finally trigger an AI worker for post-processing tasks.

Keep in mind, I had practically zero backend implementation experience before this. Accomplishing this in less than 8 hours of focused work felt genuinely impressive to me. Now, my macOS app doesn’t force the user to wait for this entire process, it uploads the file quickly, and the status updates happen asynchronously in the background. And importantly, I had a lot of fun taking those first steps into backend development.

So, let’s quickly recap how AI has been helping me so far:

Rapid Component Implementation: Building functional UI elements like paywalls in minutes, not hours.
Full Application Development: Creating entire, user-facing applications like Postr in spare time over a couple of months, despite personal life challenges.
Bridging Skill Gaps: Bootstrapping projects in unfamiliar domains, like native macOS development, within a day by leveraging existing code and AI guidance.
Lowering Activation Energy: Making it feasible to tackle projects (like this website) that previously seemed too time-consuming for the available time outside work.
Accelerated Learning & Implementation: Enabling rapid development of new systems, like the backend file processing workflow, even without prior experience in that specific area.
Maintaining Momentum: Providing the quick wins and tangible progress needed to stay motivated and see projects through to completion, similar to the boost from a co-founder.

What if I Don’t Code on Weekends?

Okay, maybe coding during evenings or weekends isn’t your thing, and that’s perfectly fine. The good news is that AI-assisted coding isn’t just for side projects or learning new stacks. There are plenty of opportunities to leverage these tools effectively within your regular day job.

Here are some ways I’ve personally used AI assistance in a professional setting:

Drafting Documentation and RFCs: Finally get that RFC written that you’ve been putting off. AI can help structure your thoughts, write clearly, and even generate pseudocode examples to back up your proposal.
Boosting Test Coverage: Writing unit tests, integration tests, or end-to-end tests can be time-consuming. AI can significantly speed up the process of generating test cases and boilerplate code.
Rapid Prototyping (POCs): Product teams often have ideas they’d love to see prototyped, but developer bandwidth is limited. AI can make building a functional Proof of Concept feasible in a much shorter timeframe, allowing for quicker validation or iteration.
Accelerating Feature Work: Yes, you can absolutely use AI for core feature development in complex, existing codebases. Before dismissing it as impossible for your project, consider the tools available. With well-defined project-specific rules (.cursorrules), agentic workflows, integration tools like Model Context Protocol (MCP) connectors (e.g., for Figma designs), and powerful models (like Gemini 2.5 Pro MAX), you might be surprised at the productivity gains and even the quality of the output.

Start small, with self-contained components and grow steadily, you’ll see the sky is the limit.

Of course, there’s a learning curve involved in effectively using these tools. However, many companies are starting to recognize the potential efficiency gains and are willing to support their developers in learning. If your organization isn’t yet aware of these possibilities, perhaps sharing this post could help them see past the hype and understand the practical benefits.

Bonus: Shoot Your Shot at Marketing

As you get more comfortable integrating AI into your development workflow, you might find it unlocks capabilities in adjacent areas too. Take the header image for this very blog post, for instance. I didn’t need to spend time searching for the right stock photo. I created it using OpenAI’s image generation model with just a few prompts.

I started by using a thumbnail from a YouTube video by my good friend Lucas Montano as a reference point and iterated from there. Here’s a glimpse of the process:

Initial AI image generation based on reference

Second iteration of AI image generation

Final header image generated by AI

This is just one example, but it highlights how AI can augment skills beyond pure coding, potentially helping with design, marketing assets, and more.

So, what are your experiences? Are you using AI in your daily development? What surprising benefits or challenges have you encountered? I’d love to hear your thoughts and continue the conversation. Find me on Twitter @filipealva and let’s discuss!

MCP: Function Calling on Asteroids

Wed, 09 Apr 2025 00:00:00 GMT

I’ve spent the last month deep-diving into Model Context Protocol (MCP) so you don’t have to. Between wading through GitHub repos, testing implementations, and reading every piece of documentation I could find, I’ve developed strong opinions on whether this is worth your time.

The AI landscape keeps evolving at a maddening pace. Yesterday it was a plain conversational interface, today it’s function calling and agents, tomorrow who knows? The result: developers constantly rebuilding the same core functionality just to handle the latest AI feature.

MCP cuts through this chaos with a refreshingly pragmatic approach. It’s not introducing yet another AI capability, it’s standardizing how all AI capabilities connect to the real world. Think of it as function calling on asteroids.

Why MCP Actually Matters

The whole point of MCP is solving the fragmentation problem. It’s not trying to replace function calling or agents or any other extension approach. It’s creating a universal standard that can accommodate all of them.

Think about it like this: before USB, connecting things to computers was chaos. Every device needed its own proprietary connector, and nothing worked with anything else. The MCP developers themselves often use this exact USB-C analogy when describing their vision. They’re quite literally doing for AI what USB did for hardware, creating a standard interface that just works across the entire ecosystem.

When an LLM needs real-time information or specialized capabilities, MCP creates a consistent way to request and receive that data through a client-server architecture. The model doesn’t need to know the specifics of how each capability works under the hood. It just needs to follow the protocol.

What’s amazing is how simple yet powerful this approach is. The LLM gets continuously updated context and maintains a persistent connection with real-world capabilities, but without the usual headache of completely different implementation approaches for each vendor.

Will Models Get Better at Using MCP?

Current LLMs are already getting fine-tuned for function calling. Claude, GPT-4, and others are increasingly good at it. But there’s a strong case that models will get even better at MCP specifically.

This excellent work on fine-tuning Llama 3.1 shows how even smaller models can be optimized for structured function calling. The same techniques could make models significantly better at MCP interactions, especially since MCP has such a well-defined interface.

If you’re curious which current models might work best with MCP, check out the Gorilla function calling leaderboard. These rankings give a decent proxy for which models will likely excel at MCP. This is because MCP essentially builds upon and standardizes function calling, models that already understand how to properly invoke functions are well-positioned to leverage MCP’s capabilities. The key difference is that while function calling is typically static, MCP provides LLMs with up-to-date context about available tools and their capabilities in real-time thanks to the 1:1 connection between the MCP client and the MCP server. This dynamic context window allows models to make more informed decisions about which tools to use and how to use them effectively, eliminating the need to hardcode function schemas directly into model weights.

Surprisingly Broad Industry Support

I was skeptical when I first heard Anthropic created MCP. The last thing we need is another proprietary standard from a single AI company. But the adoption has been genuinely surprising.

OpenAI, Anthropic’s main competitor, recently added MCP support to their Python SDK. When direct competitors start adopting each other’s standards, something interesting is happening.

Zapier’s aggressive move into MCP is another strong signal. They’re positioning MCP as the gateway between AI and their thousands of app integrations. For anyone curious about what’s possible, the Awesome MCP Servers repository has become the go-to resource.

MCP Invades the Apple Ecosystem

The Apple ecosystem is notoriously insular, so seeing rapid MCP adoption there is particularly telling. There are already several fascinating implementations:

The iOS Simulator MCP transforms iOS testing by turning LLMs into automated QA agents. Instead of manually validating each UI element post-development, developers can prompt the AI to “verify all accessibility elements,” “enter text and confirm inputs,” or “validate swipe actions”. All without writing a single test script. It can even take screenshots and record interaction videos as documentation. Imagine how much time can be saved by letting the AI run through standard validation flows immediately after implementing features, catching subtle UI inconsistencies that would have otherwise shipped to production, or just caught by manual testing.

For those of us constantly switching between Xcode and Cursor, the XcodeBuild MCP is a huge time-saver. Building and running iOS apps directly from Cursor without constantly hopping back to Xcode while an AI deals with the complexity for us feels like the future.

For teams using Tuist, they’ve just added MCP support too. Their implementation exposes project dependency graphs and configuration details, letting you ask questions about architecture or get help troubleshooting build issues directly from your AI assistant. Check out their docs for more details.

The MCP’s Swift SDK is the official Swift implementation of the Model Context Protocol, enabling developers to create custom MCP clients and servers natively in the Apple ecosystem. Supporting everything from iOS to macOS and even visionOS, it provides a comprehensive API for working with tools, resources, and prompts within the MCP specification. What’s particularly impressive is how it leverages Swift’s strong type system and async/await pattern to make MCP interactions feel natural to Swift developers.

Powered by the Swift SDK, iMCP is a macOS Productivity Suite MCP created by the same developers behind the Swift SDK. It enables AI systems to interact with core macOS applications through a unified protocol. With its ability to access contacts, calendar, and weather data, users can issue complex multi-system requests like “schedule lunch with Dave next Friday if it’s not raining” - and iMCP will handle checking weather forecasts and creating calendar entries across multiple applications without requiring any additional coding or API access setup.

What really caught my attention was seeing Mattt, the iOS community’s favorite hipster, putting his weight behind both iMCP and the Swift SDK. When someone who’s shaped so much of the Apple development ecosystem jumps on board this early, it feels like a strong sign we’re onto something genuinely valuable here, not just another AI hype.

In fact, you should read Mattt’s article on MCP as he goes much deeper than I can here, offering the kind of technical insight that only comes from someone who’s not just exploring it but actively building useful MCP servers and the Swift infrastructure so more people can do the same.

So What Now?

MCP feels different from the usual AI hype cycle. It’s solving a real problem developers face daily: how to extend LLMs with real-world capabilities in a consistent way.

The broad adoption across competitors, the rapid integration into specialized ecosystems like Apple’s, and the focus on standardization rather than reinvention all point to MCP having serious staying power.

I’m curious, what would you build with MCP? Do you think this will become the definitive standard for AI extensions, or will we see competing approaches? Drop your thoughts on Twitter @filipealva and let me know if you’re as cautiously optimistic as I am.

With MCP, I’m finally seeing AI solidly moving into an agentic approach that can seamlessly integrate with the tools and applications we already use every day. This isn’t just about making AI smarter, it’s about making our existing software more powerful by giving AI models a standardized way to work with them. And this is just getting started.

When Great Ideas Make No Money

Wed, 02 Apr 2025 00:00:00 GMT

Remember that late-night coding session when you couldn’t stop because an idea had completely consumed you? The room grows dark, coffee grows cold, but your fingers keep dancing across the keyboard because something inside you knows this idea needs to exist in the world. Logic and business sense be damned: you’re building this thing.

I lived in that state for months while creating TMCBAE (This Meeting Could Be An Email), and the journey taught me lessons I never expected to learn.

The Siren Call of Building Without Validation

As developers, we’re taught early and often about the importance of product validation. Talk to users. Test your hypothesis. Find product-market fit before investing months of development. It’s Indie Hacking 101.

And yet, armed with over a decade of professional experience, I threw all that wisdom out the window when I built TMCBAE, a Tinder-style app for canceling unnecessary meetings.

Why? Because I just really, really wanted to build it.

The mystery here isn’t why the app didn’t become commercially successful. That part was predictable. The real enigma is why experienced developers like myself sometimes deliberately ignore everything we know about successful product development and build things anyway.

The Curious Case of a “Tinder for Canceling Meetings”

The concept was simple but audacious: create an app where team members could swipe right on meetings they felt could be improved or eliminated, and when enough people matched on the same meeting, they’d collectively vote on better alternatives.

Even as I started building, the red flags were unmistakable:

Users couldn’t get value from it alone, they needed teammates to join
Not just any teammates, but specifically colleagues with overlapping meetings
The app required both critical mass and organizational cultural alignment
The cultural shift required for widespread adoption was massive

These weren’t minor hurdles, they were Mount Everest-sized adoption barriers. I knew this.

Yet I kept building.

The Technical Marathon: From Calendar API to Multi-Team Support

What followed was months of intense work on several key technical challenges:

Google Calendar Integration

Understanding how to integrate with Google Calendar’s API was the first major hurdle. I spent considerable time learning the ins and outs of the API, fetching all the data needed to provide a great swiping experience.

Going through Google’s OAuth review process to get access to the calendar scopes I needed was far more work than I expected. The review process was rigorous, requiring detailed explanations of how user data would be handled.

Once approved, I faced numerous edge cases in the calendar data:

Recurring meetings with complex patterns
Various meeting types that needed to be handled differently
Ensuring the right events appeared for swiping

Building the Core Functionality

Beyond the calendar integration, I needed to build:

A matching system to identify when enough team members wanted to change a meeting
A post-match voting system so people could participate in deciding how to transform “meetings that could be an email”
Subscription handling (with RevenueCat making this part more manageable)
Authentication flows
An in-app account deletion feature required by Apple

The Multi-Team Pivot

After initial beta testing, I discovered that multi-team support would be a game-changer for users. This meant implementing:

A team management system
One-to-many subscription approach
Ensuring meetings were correctly associated with the right teams

This addition significantly increased the scope, but seemed essential to deliver real value.

The Design Transformation

At this point, my friends who initially feared I was going crazy for pursuing this “Tinder for cancelling meetings” idea started to give me some praise. After all, it represented a substantial amount of work.

This is when Bruno Quadros, an old friend of mine and a great Product Designer, decided to put some time into redesigning the app and creating a great app icon. His work transformed the look and feel completely, making the app incredibly polished. This meant more development time before launching, but the visual upgrade was worth it.

Launch Day: Dreams Meet Reality

When TMCBAE finally launched, I was extremely happy to see my vision come to life. Some beta testing teams were interested in expanding their use, which was encouraging.

The timing seemed perfect: many companies were trying to be more efficient by reducing meetings in the aftermath of pandemic-induced remote work. The meetings madness was draining team efficiency, and people were looking for solutions.

Even Shopify had launched an extension to show how much their meetings were costing a few months earlier, encouraging employees to reduce unnecessary meetings. This trend seemed to validate the need for a tool like TMCBAE.

Some users found the app super cool and a great conversation starter to help teams reduce meetings without being rude, while also providing alternatives to canceled meetings.

However, I discovered something unexpected: some people actively want meetings. They enjoy the sense of control meetings provide and fear missing important conversations. There’s a real attachment to synchronous communication, even when async processes might be more efficient.

I encountered extreme resistance to adoption, even though many people silently believed that fewer meetings could lead to better work.

So Did It Fail? Yes and No

From a financial perspective, TMCBAE was a spectacular failure. A work-intensive app that made virtually no money.

But was it really a failure?

I knew I wasn’t following the golden rules of successful indie development. I understood it was a crazy idea with significant adoption friction. My goal wasn’t primarily financial, it was to develop my first app with AI assistance and to address a topic I cared deeply about: reducing unnecessary meetings.

By those measures, it accomplished its purpose:

I got back to building my own apps in my spare time
I learned a tremendous amount about using AI to write code (without AI, I wouldn’t have been able to ship everything I wanted to btw)
It gave me material for this very blog post, sharing lessons on how not to build your ideas. It is worth it a share, isn’t it? :P

The Technical Growth Accelerator

Beyond the product itself, TMCBAE served as an intensive technical growth opportunity, forcing me to tackle:

Modern iOS development patterns
Complex API integrations
Puzzling match-making system
Subscription management
Team-based permission systems

These skills have proven valuable in subsequent projects, making the time investment worthwhile beyond the app itself.

The Paradoxical Wisdom of Building “Impractical” Things

Perhaps the most important lesson from TMCBAE isn’t about product validation or market fit, but about the value of building things that matter to you personally, even when conventional wisdom suggests otherwise.

Sometimes the greatest learning comes not from following best practices, but from intentionally breaking the rules to see what happens. Sometimes you build not to succeed commercially, but to succeed personally, to grow, to create, to express.

Would I recommend other developers follow my approach? Probably not. The traditional advice about validation exists for good reason.

What I can say with certainty is that there’s tremendous value in every shipped project, regardless of its commercial outcome. Each deployed app, each solved problem, each technical challenge overcome becomes part of your developer DNA, shaping how you’ll approach every project that follows.

What rules are you following that might be worth questioning? What idea won’t leave you alone, despite all practical considerations? Maybe that’s exactly the project that will teach you what you most need to learn.

After all, sometimes you can just build stuff.

Hello, (new) world!

Sun, 31 Mar 2024 00:00:00 GMT

Editor’s note, 2026: the site this post celebrates has since been rebuilt from scratch, AI-natively, as the one you’re reading now. That story is its own post.

It’s been a decade since I started my journey as an iOS developer. Ten years immersed in the Apple’s ever-expanding ecosystem. I loved it, built a career on it, and became comfortable in that space. But something was missing, that electric feeling of discovery and possibility I felt when writing my first lines of code.

And then AI-assisted coding entered the scene.

A Spark Reignited

When I first experimented with AI coding assistants, something unexpected happened. That long-dormant excitement, the thrill of building something from nothing, of watching ideas materialize through code came rushing back. For the first time in years, I felt like a beginner again, but with the advantage of seasoned experience guiding my explorations.

This blog is my way of documenting this journey: exploring new technologies, building with AI, and sharing what I learn along the way.

2024: Testing the waters

Last year, I’ve launched two apps built entirely with AI assistance during my spare time:

TMCBAE (This Meeting Could Be An Email): An app that helps teams reduce unnecessary meetings by allowing members to swipe and vote on better alternatives, similar to dating apps but for meetings. Available on the App Store.
Postr: An AI-powered social media assistant that learns from accounts and styles you admire to help create engaging posts. Available on the App Store.

Both projects taught me incredible lessons about AI-assisted development and pushed my understanding of what’s possible. I’ll be sharing detailed breakdowns of how I built each one in upcoming posts.

Meta: This Website Was Built With AI

Perhaps the most meta aspect of this journey is that the very website you’re reading was also built using AI. Despite having limited experience with modern web development (it’s been years since I built a website), I was able to create this blog in a single Saturday using Next.js, with Cursor IDE and Claude Sonnet 3.7 MAX as my companions.

A few years ago, this would have been impossible. Learning Next.js from scratch would have taken weeks, and implementing a functional blog would have required extensive trial and error. But with AI guidance, the learning curve flattened dramatically.

AI: A Plane for the Human Mind

If, as Steve Jobs famously said, computers are “a bicycle for the mind,” then AI-assisted tools feel like upgrading to a plane. The acceleration in productivity and creative output is not incremental, it’s transformational.

In the coming posts, I’ll share specific techniques I’m using with tools like Cursor, practical examples of AI-assisted coding, and honest reflections on both the benefits and limitations I’ve encountered.

If you’re as excited about this new world as I am, I’d love to hear from you. Share this post and drop me a tweet at @filipealva to continue the conversation.

Here’s to new beginnings, endless possibilities, and code that writes itself (well, almost).