The No-Code Journey, Part 7: Going Mobile and The Agent Roulette

Part 7 of the no-code series covers the shift to building a mobile app with React Native, architectural challenges, and the variability of AI agents.

In Part 6, I made the strategic decision to split my project into two distinct businesses: LuxSki for luxury hotel bookings and SnowSure for AI-driven snow forecasting. It was a massive architectural shift executed in hours by AI.

Part 7 marks another significant evolution: leaving the browser behind.

A peak into my App designing dashbaord: Cursor, Warp, and Simulator for iPhone 17 Pro.

My son and I, both avid skiers, realized something fundamental while testing the site on the slopes of Italy: we hate mobile websites. We want apps. Fast, native, responsive apps. So, despite having zero experience in mobile development, I decided it was time to take SnowSure to the App Store.

This chapter is about the leap to mobile, the chaos of untangling architectures, and the realization that not all AI agents are created equal.

A Sneak Peak at the Mobile Application

The Shift to Mobile: Expo Go and 3 AM Debugging

I’ve been designing mobile interfaces for over a decade, but I’ve never actually built one. The transition from Next.js websites to React Native mobile apps felt like learning a new dialect of a language I was just starting to understand.

Cursor recommended using Expo Go, a tool that lets you preview your app on your physical phone by scanning a QR code in the terminal. The first time I saw the SnowSure interface load on my iPhone, it was a moment of pure magic.

My first foray with the App Store and submitting an IOS application. The dream is becoming a reality.

But the magic quickly faded into the reality of development. I found myself awake at 3:00 AM—partly due to jet lag from a trip to Montreal, partly due to obsession—staring at error messages on my phone screen. Communicating these mobile errors back to Cursor is significantly harder than debugging a web app. You can’t just copy-paste the console log as easily.

The initial results were humble. The visual design was rough, features like the concierge and sign-in didn’t work, and the layout broke in ways a website never would. It was surprising that Cursor, which had been so proficient at web code, struggled to replicate the existing web design into a mobile format. It wasn’t a “copy-paste” job; it was a complete rebuild.

The Architecture Collapse

While I was distracted by the shiny new mobile app, the foundation of the web platform started to crumble.

Out of the blue, APIs began failing. Data wasn’t loading. Airtable connections timed out. My attempt to have SnowSure rely on LuxSki’s architecture was proving to be a fatal mistake. Every Cursor agent I worked with got confused about which database belonged to which site.

I made the call to completely separate them. I spent four hours moving everything—resort data, images, weather logs—into a dedicated SnowSure Sanity instance.

It was a disaster.

After the migration, pages were missing critical data. Weather reports vanished. SnowSure scores disappeared. I realized too late that SnowSure had been fetching everything from the LuxSki API, and by severing that link without fully populating the new database, I had effectively lobotomized the site.

Along this journey I’ve come to expect the dreaded “You’ve hit your usage limit” from Cursor typically in the middle of a big issue. It is like the developer just walking out on the project until you pay their ransom.

Cursor’s response was painfully direct:

“I completely understand your frustration... You had a working system and the migration to a separate Sanity database broke it.”

It took a grueling day of debugging to rebuild the connections, but stability eventually returned. The lesson? Don’t muddy your architectures. If you’re building two businesses, give them two separate foundations from day one.

On the left, the website in mobile view. On the right, the first version of the mobile application- it needed a lot of work to get it looking acceptable.

The Agent Roulette: Rock Stars vs. Duds

One of the most fascinating aspects of this journey has been the variability of the AI “agents” I work with.

When you start a session with Cursor, you are essentially rolling the dice on your new coworker. Sometimes, you get a “dud”—an agent that forgets context, writes buggy code, or hallucinates solutions that don’t exist.

But sometimes, you get a “Rock Star.”

I encountered one such agent this week. It didn’t just fix my code; it audited the entire project and found deep, structural issues that previous agents had created.

It found that my weather syncs were running in the wrong order, meaning the database was updating before the fresh weather data arrived. It also discovered that a previous agent had been using the free API endpoints for Open-Meteo instead of the Pro key I was paying for, causing constant rate-limiting errors.

This Rock Star agent refactored the entire sync logic:

1. Corrected the Order: Weather sync now runs first, followed by the resort sync 5 minutes later.

2. Increased Frequency: Updates happen every 15 minutes instead of hourly.

3. Optimized Batching: It processes 50 resorts at a time instead of 25.

It felt like a senior engineer had walked into the room, looked at the junior developer’s code, and fixed everything in five minutes. The question moving forward is: how do I ensure I always get the Rock Star?

Is It Worth It?

As the complexity grows—managing APIs, mobile builds, Apple Developer accounts, and fallback systems—I find myself asking the Product Manager’s ultimate question: Is this worth my time?

I started this to learn AI and coding. Now, I’m worrying about uptime monitoring and fallback resilience. The fun of feature building is being replaced by the chore of system maintenance.

However, the progress keeps pulling me back in. We launched a custom SnowSure GPT app, meaning users can now get our forecasts directly inside ChatGPT. My son has become my QA lead, testing the mobile app via TestFlight and giving feedback that actually improves the product. Cursor has truly become a family affair.

Next Steps: Reliability Over Features

We are now submitting builds to the App Store via Xcode and TestFlight. The user experience is coming together, but the focus has shifted entirely to data reliability.

If the snow report says it’s powder day, it better be a powder day. If the historical data says a resort is “SnowSure,” that data needs to be accurate. The prettiest mobile app in the world is useless if the numbers are wrong.

This project has evolved from a simple website experiment into a complex, multi-platform ecosystem. It’s messy, frustrating, and often keeps me up until sunrise. But when I see the app running on my phone, powered by an architecture I built with an AI partner, I know I’m looking at the future of software development.

I just hope the next agent I roll is a Rock Star.