At 3:50 PM on August 11, I made the first commit setting up the development environment for an iOS app called Profit Calculator. Implementation finished at 9:40 PM the same day. The next afternoon I produced the full set of App Store assets and submitted. It passed review and is on the App Store now.

By the numbers: about 3,300 lines of Dart, 25 files, 31 tests, 37 commits, roughly six working hours of implementation.

This isn't a brag. Everything was in git log, and when I went back through it, the interesting part was that the speed had almost nothing to do with how fast the AI writes code. This post is the full timeline plus the actual reasons it took six hours.

What you'll learn

  • The real timeline from environment setup to App Store submission, with commit timestamps
  • Why every screen existed 27 minutes in — a "won't build" list written before any code
  • The plausible-but-wrong formula the AI wrote (the honest part)
  • Dropping the monetization model halfway through the day
  • What kind of app fits a one-day build, and what doesn't

The short version: speed came from deciding, not generating

Claude Code generates code fast. That's table stakes, not the reason. What actually mattered:

  1. A "won't build" list came first — iOS only, iPhone only, Japanese only, no server, no accounts. Written into the spec's Won't section before a line of code
  2. The development process was already templated — requirements → spec → scaffold → implement → store assets, with the shape of each deliverable established on previous apps
  3. When in doubt, cut — a feature built at 7:03 PM was reverted at 7:30 PM, and the freemium model designed in the morning was thrown out at 8:43 PM

Without those three, asking Claude Code to "build me an app" probably doesn't finish in a day. Let's go through them.

What I built: the profit calculator I wanted for myself

A profit simulator for side businesses and small operators. Enter price, cost of goods, platform fees, ad spend and fixed costs, and it shows what's actually left in real time. Five functions: profit calculation, target-profit reverse calculation, break-even, price comparison, and ad-spend simulation. All data on-device. No sign-up, free, no ads.

I built it because I was the one who needed it. I run two AI image-generation apps, and I've done "at ¥X per month with N users, minus API cost, what's left?" in spreadsheets more times than I want to admit. So the app ships with a template for exactly that:

AI service variable cost = API cost per call × average calls per user × number of users

It switches between subscription, pay-per-use, and a subscription-plus-credits hybrid. If you're an indie developer building anything on top of an AI API, you'll recognize why this calculation matters.

The full timeline

Straight from git log.

Time What happened
3:50 PM Environment setup (requirements, MVP spec, CLAUDE.md, facts file, hooks, CI scaffold)
3:55–3:57 PM A burst of decision commits (billing boundary, iOS-only first release, 100-item history cap)
4:03 PM Flutter project init + MVP scaffold
4:09 PM Calculation engine + 12 acceptance tests
4:13 PM Data layer (JSON models, Hive repository, template definitions, Riverpod)
4:17 PM All screens implemented (home, four calculators, projects, history, settings)
4:37–7:39 PM Features and polish (ad simulation, billing-model variants, iOS-style redesign, app icon)
7:30 PM Slider fine-tuning feature reverted
8:43 PM Freemium dropped → fully free, plus cross-promotion to my other apps
9:40 PM Privacy policy and terms links (implementation ends here)
Aug 12, midday App Store assets (title, keywords, description, screenshot plan) created and submitted

Setup started at 3:50. Every screen existed by 4:17. Twenty-seven minutes. That looks like magic in isolation, but there's a trick.

Reason #1: the spec existed before the code

The 3:50 commit contained no code. It contained documents: a requirements doc, an MVP spec, a facts file (single source of truth for app name, feature count, URLs), and CLAUDE.md — the instruction file Claude Code reads.

The part that did the most work was the spec's Must / Should / Won't split. The Won't section said:

Not building this time: bookkeeping, tax filing, tax calculation, invoicing, bank integration, inventory, AI business diagnosis, team sharing, cloud sync, account registration

A profit calculator has infinite temptation to grow into an accounting app. All of that was refused before writing started. Platform was narrowed too: iOS only, iPhone only, Japanese only. No server, no auth — the same "borrow less, ship faster" dynamic I wrote about with native Swift and CloudKit, happening in Flutter this time. (Flutter because an Android version is planned later.)

All screens in 27 minutes wasn't because Claude Code was fast. It was because only 27 minutes of work had been left on the table.

Reason #2: acceptance criteria became tests directly

The other thing to notice: 12 acceptance tests landed at 4:09 PM. The spec had criteria like "with a ¥30,000 budget and ¥1,000 CPA, 30 acquisitions is break-even," and those went straight into test code.

test('subscription: API cost grows with usage while revenue stays fixed', () {
  // ¥1,000/month × 100 users, ¥5 per call × 20 calls avg → ¥10,000 API cost
  final input = buildInput({
    TemplateField.price: 1000,
    TemplateField.quantity: 100,
    TemplateField.apiUnitCost: 5,
    TemplateField.avgUsageCount: 20,
    TemplateField.fee: 10,
    TemplateField.fixedCost: 20000,
  }, feeIsRate: true);
  final result = calculator.calculate(input);
  expect(result.revenue, 100000);
  expect(result.costOfGoods, 10000);
});

A calculator has unambiguous inputs and outputs, so this workflow fits perfectly. The engine is pure Dart, isolated from UI, locked down by tests before any screen exists. Final count: 31 tests. When an AI is writing the code, shaping the problem so a machine can judge correctness is what makes it safe.

The honest part: the AI wrote a plausible, wrong formula

It looks smooth so far. But at 5:49 PM there's this fix commit:

fix: hybrid model → subscription + credits (revenue only from credit purchases; API cost tied to total usage)

For the subscription-plus-credits hybrid, the formula Claude wrote initially linked revenue and cost the wrong way. The code was clean. It ran. If I'd written the test with the same wrong understanding, the test would have passed too. This wasn't a code bug — it was a business-model bug.

I only caught it because I actually operate a subscription-plus-credits app and knew "revenue is only what people buy in credits; API cost tracks total credits consumed." Even in the AI era, domain review stays a human job. Arguably it becomes the only job.

Same day: a slider fine-tuning feature added at 7:03 PM was reverted at 7:30 PM. Real-time recalculation was already enough; the slider just cluttered the screen. Throwing away 30 minutes of work without hesitation is a hidden benefit of cheap generation. Building fast is also discarding fast.

Dropping the monetization model mid-day

The biggest pivot in the timeline is 8:43 PM. Ten minutes into the day, at 3:55 PM, I'd committed a freemium design — "3 saved calculations free, Pro one-time purchase." At 8:43 PM I killed freemium and made it fully free.

The reason was simple: after using the finished app, "charging for a calculator" didn't feel viable. Instead I put a "more apps by this developer" section in Settings and decided to ship it as a business card that sends people to my other apps. Removing IAP also simplified both implementation and review.

Is there a point to building a zero-revenue app? If you do indie development for a while, one free app in the store becomes an entrance to your developer page. I valued that over chasing a few hundred yen. And that decision was only possible because I wasn't attached to the morning's design.

What fits a one-day build

Fits Doesn't fit
Data Stays on device Needs a server-side ledger
Function Clear I/O (calculate, convert, record) Calls an external API (key must be protected)
Auth None Login required
Billing None or one-time Subscription (needs server validation)
Correctness Machine-checkable with tests The look and feel is the product

Apps like my AI image generators — backend to protect the API key, abuse prevention, billing infrastructure — will never fit in a day. Conversely, for a first indie app you actually ship, an on-device calculator or tracker like this is close to ideal.

And once more: "one day" was not one day from zero. It was reproducible because the process from requirements to store assets had been established and templated on earlier apps. If you want to go faster, document your own development process before you optimize code generation.

Takeaways

  • About six working hours and 37 commits took a profit calculator from implementation to App Store submission
  • The speed came from a pre-written "won't build" list and a templated development process
  • Wiring acceptance criteria directly into tests lets a machine guarantee correctness even when an AI writes the code
  • But the AI will write a plausible, wrong formula. Domain review is the human's job
  • The finished app is free on the App Store (Japan) — the UI is Japanese, but the templates for AI-service pricing may be useful if you read the numbers

This is one of several posts on AI-driven indie development from Japan. The Japanese original has a few more details: Claude Codeでアプリを1日開発. More English articles: Village Gazette in English.