A complete beginner can build an app in hours

I carried multiple rewards cards and kept doing the same checkout-line calculation: which card earns the most for dining, groceries, a specific airline, or a hotel brand? Statement credits and card-linked offers added another layer of memory.

That became CardPecker, a private iPhone app that compares the earning rules in your own wallet, tracks recurring benefits, stores receipts, and keeps loyalty balances organized. It does not require a CardPecker account or bank login.

I began as a complete coding newcomer. Within hours, AI helped me turn the idea into a working app prototype that I could open, tap, and test. That is the genuinely new opportunity: you no longer need months of syntax study before an idea becomes something visible.

Hours can produce a working app. Weeks produce a product. The prototype proved the idea; product thinking, architecture, testing, and polish made it shippable.

I knew what the app should do: answer one question quickly, remain understandable, and keep personal data local. AI could translate requirements into Swift. It could not decide whether the requirements were good, whether the architecture would survive new features, or whether the experience deserved to ship.

The workflow from an hours-old prototype to a polished app

1. Write the product before writing the code

I started with plain language: who the app is for, what appears on the first screen, what information a card needs, how recommendations are calculated, and what must never leave the device. That became a living specification.

A prompt like “build me a credit-card app” can produce a demo, but it leaves too many decisions unstated. A better request names the goal, relevant context, constraints, and what must be true when the task is done. That is also how OpenAI’s current Codex best-practices guide recommends framing substantial coding work.

2. Use the first few hours to prove one complete path

The first version needed only categories, cards, earning multipliers, local storage, and a recommendation screen. A beginner can describe that path, let an agent scaffold it, run the app, and see a meaningful result on the same day. That immediate feedback makes learning far less abstract.

3. Spend the following weeks thinking like a product owner

Once the basic path worked, the difficult questions changed. Should hotel brands be subcategories? How should recurring credits reset? What happens when stored data changes between app versions? What should a backup contain? How can a Safari extension remain useful without collecting passwords? These are product and architecture questions, not syntax questions.

Then came hotel and airline subcategories, the Coupon Book, receipts, rewards balances, backups, offers, and a Safari extension. Each feature affected navigation, data models, privacy explanations, and future maintenance. AI could suggest structures, but I had to choose which complexity the product could justify.

CardPecker’s repository now contains more than 100 commits. That history matters because “vibe coding” should not mean one giant prompt followed by blind acceptance. It should mean a short loop:

  1. Describe one result.
  2. Let the coding agent inspect the existing project.
  3. Review the proposed plan or diff.
  4. Build and run it.
  5. Test the behavior yourself.
  6. Report the exact failure and iterate.
  7. Commit only when the slice works.

4. Ask the agent to use the real development environment

The useful leap from a chatbot to a coding agent is action. Modern tools can inspect a repository, edit files, run build commands, examine errors, and review changes. Codex works across local coding surfaces, while Claude Code operates from the terminal and can work directly with a project.

For CardPecker, that meant working inside the Xcode project rather than copying isolated snippets from a chat window. When a build failed, the error became the next piece of context. When a feature behaved badly, the agent could trace the relevant model, view, and data flow.

5. Make verification part of every prompt

“The code looks plausible” is not completion. I learned to ask for builds, targeted tests, migration checks, privacy review, and a final diff inspection. I also used the app myself: tapping empty row space, changing a credit cycle, restoring backups, scanning receipts, and checking what the Safari extension actually reads.

Some of the most important work was unglamorous. Git history shows small fixes to touch targets, labels, filters, migrations, parsing rules, and synchronization behavior. Shipping comes from resolving those details, not from generating the first screen quickly.

What AI did not—and should not—do

AI helped me code the product. It was not the source of truth for the product.

AI did not invent card facts

Reward multipliers, annual credits, issuer rules, transfer partners, and point valuations can change. A language model may produce an outdated number or a confident rule that never existed. Those facts must be checked against issuer and loyalty-program sources before they enter the app or an article.

AI did not fabricate firsthand experience

If I did not stay at a hotel, eat a dish, use a lounge, or visit a museum, AI cannot turn that absence into experience. It can help organize my notes and improve clarity, but the observation must originate with me. The same rule applies to this website: AI can assist the production process; it cannot manufacture authenticity.

AI did not own privacy or security decisions

“Local first,” “no bank credentials,” and “no CardPecker server” were product boundaries I chose. Any feature involving Safari page access, backups, receipts, or device storage required me to understand what data moved, what permissions appeared, and whether the public explanation matched the implementation.

AI did not replace editorial judgment

Models are good at generating smooth sentences. Smooth is not the same as true, useful, or worth publishing. I decide the angle, preserve disagreement and uncertainty, remove filler, verify current claims, and reject text that sounds authoritative without evidence.

AI did not remove responsibility

The App Store listing has my company’s name, not the model’s. A coding agent cannot accept accountability for a broken migration, misleading benefit, privacy mistake, or inaccessible screen. The person shipping the work remains responsible.

What I would tell another complete beginner

  • Aim for a working path in hours, not a complete product. Fast visible progress creates momentum without hiding the work ahead.
  • Choose a problem you understand deeply. Domain knowledge helps you recognize when the output is wrong.
  • Develop a product mindset. Ask who needs the feature, which problem it solves, what should be removed, and what failure feels like to a user.
  • Develop an architecture mindset. You do not need to write every line, but you must understand where data lives, how features connect, and what today’s shortcut will cost later.
  • Start smaller than your ambition. Make one useful path work before adding automation.
  • Ask for explanations. You do not need to memorize syntax, but you should understand the architecture and data flow you are approving.
  • Keep changes reversible. Use Git and commit working increments.
  • Never paste secrets casually. Keep credentials out of prompts and repositories.
  • Test destructive paths. Deletion, migration, restore, permissions, and failure states matter more than a polished demo.
  • Use a second review pass. Ask the agent—or another agent—to look for bugs, privacy problems, and unsupported assumptions.
  • Expect weeks of iteration. More than 100 commits is not evidence that AI failed. It is evidence that software is refined through many decisions.

AI did not make me a veteran engineer overnight. It made it possible to learn through a real project and ask for implementation help at the moment I needed it. The bottleneck moved from “Can I remember this syntax?” toward “Can I define the right product, choose a sustainable structure, and verify the behavior?”

Next: a practical vibe-coding video

I plan to turn this experience into a beginner-friendly YouTube walkthrough using current coding agents such as Codex and Claude Code. The goal will not be a staged “app in five minutes” demo. It will show the real loop: define a tiny feature, inspect the repository, plan, edit, build, test, review the diff, recover from a mistake, and commit.

That is the version of vibe coding I can recommend: ambitious about what AI makes accessible, cautious about what it can get wrong, and grounded in evidence every time the work touches facts, privacy, money, or other people.

See why CardPecker exists, explore the current app, or read how to track card benefits before they expire.

This is a firsthand builder story, not a claim that coding agents eliminate the need for testing, security review, specialist expertise, or responsibility. Product and tool capabilities change; verify current vendor documentation.