u/nayefisaac

Kling x DaVinci Resolve

A few years ago, I went back to school and started using AI to help me create flashcards. That was when the original idea hit me: what if I turned this into a SaaS product?

At the time, AI coding tools were not nearly where they are today, so I put the idea on the shelf. Fast-forward to now, and so much has changed. AI coding has gotten dramatically better, so I decided to revisit the idea — but this time, instead of building it as a SaaS, I wanted to turn it into a mobile app.

I decided to give Claude a try and started by creating a skills.md file with clear instructions. Inside that file, I included the suggested tech stack, key features, design direction, app functions, and the overall product vision.

My original stack looked like this:

- Frontend (Mobile) React Native (Expo).

- Backend API Node.js + Express.

- AI Processing Claude (via API).

- Database PostgreSQL (via Supabase).

- Auth Supabase Auth (Email login).

- Mobile App Deployed via Expo.

- Payment Stripe.

- File Storage Supabase Storage.

It did not take long to create the first working MVP. At that stage, though, “working” mostly meant the front end and basic backend structure existed. Most of the actual functionality still needed to be connected.

From there, I started adding SQL tables, API keys, authentication, payments, email, and AI functionality. I used Expo for mobile testing, Supabase for the database, Stripe for payments, Anthropic for the AI features, and Resend for emails. My domain was hosted through Hostinger, and I kept everything running locally while I tested the MVP.

Since the app was very basic at first, I had to build it feature by feature. One thing I learned quickly is that the best approach is to focus on one change at a time. If I wanted to rearrange part of the design, add a new feature, fix a bug, or change the user flow, I would prompt Claude to handle that specific task instead of trying to do everything at once.

That process took about two to three months before the app started to feel like the product I originally had in mind.

Once the core app was built, I went through and tested every feature. Anytime I ran into a bug, I would document it, give the issue to Claude, and have it help me fix the problem. I also used ChatGPT, Gemini, and Grok for second opinions, debugging help, wording, planning, and general feedback. For icons and graphics, I used Nano Banana to help generate visual assets.

As I kept working, I made constant additions and revisions to Supabase, environment variables, API keys, and app logic. The AI features used the Anthropic API. Emails were handled through Resend. Payments were originally handled through Stripe. Everything slowly came together piece by piece.

At the same time, I was setting up my Apple Developer account and gradually working through the App Store side of the process. Getting from local MVP to something ready for submission took around 20 to 23 builds.

When I was finally ready to move beyond local testing, I used Railway to host the backend. Setting up Railway took time. I had to work through deployment errors, adjust the backend, configure the correct environment variables, redeploy changes, and keep testing until everything worked properly in production.

That was when the TestFlight phase began.

Being able to test the app on my iPhone through TestFlight instead of Expo made the project feel much more real. I tested the app, fixed more bugs, rebuilt, redeployed, and kept tightening everything up.

Once I was happy with the finished version, it was time to create the final iOS build for review. I completed the app profile, filled out the required App Store information, uploaded the build, and submitted it for review.

That started the next major phase.

The biggest hurdle was removing Stripe payments and switching to Apple-compliant in-app purchases. I had to create subscriptions inside App Store Connect, set up the products, build the paywall, and connect everything through RevenueCat.

On top of that, there were several App Store guidelines and policies the MVP did not fully meet. I had to go through the feedback, make revisions, rebuild the app, upload new builds, resubmit for review, get more notes back, fix more issues, and repeat the process.

It was frustrating at times, but the process was also extremely valuable. Every rejection made the app better. Every bug fix made the product stronger. Every rebuild taught me something new.

Eventually, after a lot of persistence, AI assistance, and consistent work, the app was finally approved.

And honestly, that is just the beginning.

Building the app was one phase. Getting approved was another. Now comes the real work: improving the product, getting users, listening to feedback, and continuing to build something useful.

Some of the biggest lessons I learned:

Start with a clear product vision, but be flexible as you build.

Use AI coding tools like a development partner, not a magic button.

Work on one feature or fix at a time.

Test constantly.

Expect App Store review to take multiple rounds.

Keep your environment variables, API keys, and backend setup organized from the beginning.

After your initial MVP is complete, copy the project into iOS and Android folders because each requires very different revisions.

Use multiple AI tools for second opinions when you get stuck.

Do not treat approval as the finish line. It is the starting line.

Don’t over think branding and small details (this was always a weakness of mine that held me back). Just roll with it and let AI make decisions for you, even if you don’t fully like them.

This whole process showed me how powerful AI-assisted development has become. A few years ago, this idea felt out of reach. Now, with the right tools, patience, and consistency, I was able to take it from an old idea to a real app on the App Store.

The app is called Wyld Cardz. It allows you to turn notes, textbook screenshots, and study material into flashcards, key terms, definitions, and Q&A with AI-powered study decks.