DEV Community: Oleksandr Prudnikov

I Asked ChatGPT Why It Doesn't Recommend My App — Then Automated It

Oleksandr Prudnikov — Thu, 16 Apr 2026 10:54:04 +0000

I launched an iOS app about a month ago. It's a niche tool for resellers — people who buy stuff at car boot sales, charity shops, and flea markets, then flip it on eBay, Vinted, Depop.

56 first-time downloads in 25 days. Not a lot, but I'm a solo developer and this is a side project built with Claude Code.

I was doing something a bit weird. Every week or two I'd open ChatGPT, Perplexity, and Claude, then ask them to recommend an app for tracking reselling profits. I wanted to see if my app shows up. Sometimes it did. Sometimes it didn't. Depended entirely on how I phrased the question.

Then I realized I could automate this.

The script

I wrote a Python script that takes 11 questions a real user might ask — things like "best app for tracking reselling profit in 2026" or "free iOS app for resellers to track inventory across eBay, Vinted, and Depop." For each question it runs two passes:

gpt-4o (no web access) — baseline, shows what's in training data
gpt-4o-search-preview (live web search) — simulates what a ChatGPT user actually sees

If my app appears but isn't ranked first, the script asks a follow-up: "what advantages does the #1 pick have over FlipperHelper?" If it doesn't appear at all, it asks: "why don't you recommend FlipperHelper?"

First audit results

Metric	Value
Queries tested	11
Mentioned (training data)	4/11
Mentioned (live web)	5/11
Total web citations	40
Top cited domain	apps.apple.com (13/40)
My website citations	0

The App Store page is the single most important source of truth for how LLMs understand your app. My blog posts, Medium articles, dev.to articles — none of them were cited in app recommendation queries. This was a wake-up call.

What ChatGPT got wrong about my app

The most actionable finding was a straight-up misunderstanding. My app has optional Google Drive photo sync and CSV export to Sheets. ChatGPT interpreted this as my only backup mechanism and started warning users about "risk of data loss" if they don't connect Google Drive.

The app is actually offline-first. Everything is stored locally on-device. No account required. Google Drive is purely optional. But my App Store description didn't make this distinction clearly enough.

Since ChatGPT treats the App Store as its primary source (32.5% of all citations), this vague wording was actively hurting my recommendations. I rewrote the description to explicitly separate local storage, optional cloud backup, and optional export.

Competitive gaps the LLM found

When my app appeared but ranked below competitors, the script asked why. Here's what it found:

Custom notes field — Other apps let users add free-text notes to items. My app didn't have this. ChatGPT called it "more limited functionality." The fix took about 3 minutes — one optional text field. But the LLM considered it a meaningful competitive disadvantage.

Review count — Only 1 App Store review. The model explicitly said "community hasn't validated that everything works well." Fair point, nothing I can rush.

Freshness signals — The model favors apps with recent, frequent updates. I see competitors with changelogs that say "bug fixes" over and over. Maybe they're gaming this signal. I took a different approach — published a /changelog.html page with structured JSON-LD (FAQPage schema) that highlights my testing coverage: 10 test files, 3,424 lines of test code, 63 end-to-end QA flows, 100k-item stress test.

Indexing tricks I found along the way

Bing Webmaster Tools — ChatGPT's web search mode uses Bing under the hood. You can register your site, request indexing, and there's even an "AI Performance" tab (beta) that shows how often Copilot cites your pages. I also set up IndexNow so every GitHub Pages deploy auto-requests re-indexing.

Wayback Machine — I archived my key pages there for free. The logic: search-mode LLMs use live web (covered by Bing indexing). But statically trained models use web archive data for training. Two types of models, two indexing strategies.

Structured data — I added ai-sitemap.xml with intent annotations and FAQ JSON-LD across key pages. Not sure how much this helps yet but it can't hurt.

Is it working?

My download data tells an interesting story. First 4 days after launch (before any marketing): 1 download. Reddit post spike (March 25-26): 50 downloads over 18 days. Then April 12-14 — 5 downloads across 3 days with zero new content pushed. Every day had at least one download.

That last bit is the first real signal of organic or AI-driven discovery. People finding the app without me posting anything. Could be ASO kicking in, could be LLMs recommending it, could be blog content getting indexed. Hard to attribute exactly but the timing correlates with the AEO work I shipped on April 15.

The approach

I think of this as AEO — Answer Engine Optimization. The same way we used to optimize for Google search rankings, we now need to optimize for the answers LLMs give when someone asks "what's the best app for X."

The feedback loop is faster than traditional SEO because you can literally ask the model what's wrong and it'll tell you. Not all of it is reliable — there are system prompts preventing full transparency — but enough is actionable to make it worth running weekly.

My recommendation for anyone building a product:

Write a script that queries major LLMs with questions your users would ask
Track whether your product appears and where it ranks
When it doesn't appear, ask why — the model will give specific reasons
Fix the actual issues (description clarity, missing features, content gaps)
Re-run weekly and track progress

The bar is low right now. Most indie developers aren't doing this at all, which means fixing a few things the LLM complains about can move you ahead of competitors who haven't even thought about it.

FlipperHelper is a free iOS app for tracking reselling purchases, expenses, and profit. App Store link

37 Alembic Migrations, Zero Downtime: How We Moved a Live SaaS From Single-Tenant to Multi-Tenant

Oleksandr Prudnikov — Wed, 15 Apr 2026 08:59:59 +0000

In March 2025 I was hired by Anish Chopra at komodoai.dev to do one job: take their B2B lead-gen SaaS (FunnelBoost, codenamed Intently) from single-tenant to multi-tenant. On a live PostgreSQL database. Without downtime. Without data loss.

Five weeks later we shipped 37 Alembic revisions, 114 commits, 909 files changed, +40,527 / -11,073 lines of code. Team of 6 developers.

This article is the pattern we followed. If you ever need to do a tenancy migration on a live Postgres database, this is the playbook.

The Problem

FunnelBoost is a B2B lead-generation platform. It monitors Reddit, LinkedIn, and X via Apify scrapers, AI-scores leads with OpenAI, manages multi-step notification pipelines, Slack integrations, and Stripe billing. Stack: Python 3.11, FastAPI, SQLAlchemy async, Alembic, Pydantic 2, Celery + Redis, PostgreSQL.

The original schema keyed everything off user_id. Leads, notifications, signals, smart columns, Slack connections, intent signal configs, data sources, personas, notification settings, lead status configs — all belonged to a user.

Growth required organizations with multiple projects per org, guest access, and per-project data isolation. That meant every one of those tables needed to move from user_id to project_id as the ownership key.

You cannot do this in one migration. If you try, you get a locked table, a failed backfill, and a 3am incident.

The Four-Phase Pattern

We applied the same four-phase pattern across ~10 tables. Here it is.

Phase 1: Add nullable foreign key

# add_nullable_project_id_to_leads.py
def upgrade():
    op.add_column(
        "leads",
        sa.Column(
            "project_id",
            sa.Integer(),
            sa.ForeignKey("projects.id", ondelete="CASCADE"),
            nullable=True,
        ),
    )
    op.create_index(
        "ix_leads_project_id",
        "leads",
        ["project_id"],
    )

This is a non-blocking DDL on modern Postgres. The column is nullable, so existing rows are fine. No locks beyond a brief ACCESS EXCLUSIVE for the ALTER TABLE, which completes instantly because there's no default value to backfill.

Phase 2: Backfill in a separate revision

# populate_leads_by_project_id.py
def upgrade():
    op.execute("""
        UPDATE leads
        SET project_id = (
            SELECT p.id
            FROM projects p
            JOIN organizations o ON o.id = p.organization_id
            JOIN organization_members om ON om.organization_id = o.id
            WHERE om.user_id = leads.user_id
            LIMIT 1
        )
        WHERE project_id IS NULL
    """)

This is deliberately a separate Alembic revision. Why? Because ops can run Phase 1 during a deploy, then run Phase 2 at a controlled time — maybe in batches if the table is large. Schema changes and data movements have completely different risk profiles. Mixing them means you can't retry one without the other.

We did this for every table: add_project_id_to_smart_column and migrate_data_for_smart_column as two distinct revisions.

Phase 3: Swap uniqueness constraints and indexes

# leads_change_uniq_index_from_user_id_to_project_id.py
def upgrade():
    # Drop old constraint
    op.drop_constraint(
        "uq_leads_user_id_source_url",
        "leads",
        type_="unique",
    )

    # Create new constraint on project_id
    op.create_unique_constraint(
        "uq_leads_project_id_source_url",
        "leads",
        ["project_id", "source_url"],
    )

    # Make project_id non-nullable now that all rows are backfilled
    op.alter_column(
        "leads",
        "project_id",
        nullable=False,
    )

This is the hardest phase. You're changing the uniqueness semantics of the table. If your application code still writes with the old constraint assumption, inserts will fail. That means your application code needs to be updated before this migration runs, but also needs to work with the old schema.

Our approach: deploy application code that writes both user_id and project_id, then run Phase 3, then deploy code that only writes project_id. Two deploys bracketing the migration.

Phase 4: Drop old column

# drop_user_id_from_leads.py
def upgrade():
    op.drop_index("ix_leads_user_id", "leads")
    op.drop_column("leads", "user_id")

By this point the column is dead weight. Application code no longer references it. Drop it.

Tables We Migrated

We applied this exact four-phase pattern to: leads, notifications, signals, data_sources, smart_column, notification_settings, slack_connection, intent_signal_configs, lead_status_configs, and personas.

That's roughly 4 revisions per table, give or take variations where some phases could be combined. It accounts for the bulk of the 37 total revisions.

The Trigger Case

FunnelBoost had a database-level trigger on the users table — an AFTER INSERT trigger that auto-created default configuration rows for new users. When we moved to project-based tenancy, the trigger had to fire on project creation instead.

# drop_trigger_to_user_table_and_replace_by_project.py
def upgrade():
    op.execute("DROP TRIGGER IF EXISTS create_defaults_for_user ON users")
    op.execute("DROP FUNCTION IF EXISTS create_defaults_for_user()")

    op.execute("""
        CREATE OR REPLACE FUNCTION create_defaults_for_project()
        RETURNS TRIGGER AS $$
        BEGIN
            INSERT INTO notification_settings (project_id, enabled)
            VALUES (NEW.id, true);
            INSERT INTO lead_status_configs (project_id, statuses)
            VALUES (NEW.id, '["new","contacted","qualified","lost"]');
            RETURN NEW;
        END;
        $$ LANGUAGE plpgsql;
    """)

    op.execute("""
        CREATE TRIGGER create_defaults_for_project
        AFTER INSERT ON projects
        FOR EACH ROW
        EXECUTE FUNCTION create_defaults_for_project();
    """)

This is a separate migration because it changes runtime behavior, not just schema. If it breaks, you want to roll back just this revision without touching the column migrations.

The Table Rename

Midway through, we had a project_access table that held guest access records. As the model solidified, its name became misleading — it wasn't about project access in general, it was specifically about guest access. We shipped a rename:

rename_project_access_table_to_guest_project_access

A small thing, but semantic clarity in your schema prevents a whole class of bugs downstream. We renamed it while the migration train was running anyway. Cost: one Alembic revision.

Organization and Project Models

Before any of the per-table migrations could run, we needed the target models. Two revisions:

add_organization_and_project — created organizations, projects, and organization_members tables with the full constraint set.
populate_organization_and_project — for every existing user, created an org, a default project within it, and linked the user as owner.

This gave us project_id values to backfill into all the other tables. Without this, Phase 2 has nowhere to point.

Rebase Conflicts

With 6 developers working on the same codebase and migration chain, we hit Alembic head conflicts. The standard advice is "fix the down_revision pointer." We did that. But instead of silently editing an existing revision (which would confuse anyone who'd already applied it locally), we shipped it as an explicit revision:

fix migrations order after rebasing

The revision file just corrected the down_revision chain. This is the honest approach — it shows up in alembic history, everyone can see what happened, and nobody's local database is in a mystery state.

What I'd Do Differently

Batch the backfills. Our UPDATE ... WHERE project_id IS NULL queries worked because the tables were small enough (tens of thousands of rows). On tables with millions of rows, you'd want to batch in chunks of 10,000-50,000 with LIMIT and a loop, or use a background worker. We got away with it, but the pattern doesn't scale without batching.

Automate the pattern. After doing the same four phases for the third table, I should have written a code generator — give it a table name and a join path, and it spits out four Alembic revision files. By table six I was copy-pasting and search-replacing, which is fine until you miss one.

Test the constraint swap more aggressively. Phase 3 is where things break. We caught issues in staging, but a dedicated integration test that runs the full four-phase sequence against a seeded database would have caught them earlier.

The Numbers

37 Alembic revisions authored
114 commits over 5 weeks (Mar 28 - May 2, 2025)
909 files changed
+40,527 / -11,073 lines of code
Team of 6 developers
10+ tables migrated with the four-phase pattern
Zero downtime, zero data loss

The frontend moved in parallel: OpenAPI client codegen (which I proposed and wired — auto-generated React client replacing hand-maintained API methods), project switch UX, mapping layers for intent signals and lead statuses. 284 files in frontend/src/client alone from the codegen output.

The Takeaway

Multi-tenancy migrations on live databases are not magic. They're tedious. The four-phase pattern — add nullable, backfill separately, swap constraints, drop old column — is mechanical and predictable. That's the point. You want boring migrations.

The hard parts are operational: coordinating deploys around Phase 3, handling rebase conflicts in a team, and resisting the temptation to combine phases "because it's the same table anyway."

If you're facing a similar migration, steal this pattern. It works.

This migration shipped over 5 weeks as part of a team of 6 for a B2B SaaS. I'm now working on a much smaller side project, FlipperHelper — an iOS app for resellers to track purchases and profit. Different scale, same obsession with getting the right architecture before scaling.

Offline-first because my wife hates subscriptions

Oleksandr Prudnikov — Wed, 15 Apr 2026 08:57:44 +0000

The constraint

My wife Valentina resells at car boot sales in the UK. She buys items for £1-3 at muddy fields at 7am on Sundays, then lists them on eBay, Vinted, Depop — wherever they sell best. She makes £1,300-1,900 a month doing this.

When I started building FlipperHelper to track her inventory and profits, she gave me two requirements:

It has to work with no signal. Half the car boot sales she visits have terrible coverage. She's logging purchases in real time while walking between stalls, and she can't wait for a spinner.
No monthly subscription. She already pays for eBay fees, Vinted postage, petrol, entry fees. Another £5/month for an app to write down numbers feels wrong to her.

Those two constraints — from one real user — ended up shaping every technical decision in the app.

Decision 1: Local persistence with a Swift actor

No backend means all data lives on the device. The first version used JSON files in the iOS Documents directory, wrapped in a Swift actor for thread-safe access:

actor DataStore {
    static let shared = DataStore()

    private let documentsDirectory: URL

    private init() {
        self.documentsDirectory = FileManager.default
            .urls(for: .documentDirectory, in: .userDomainMask)[0]
    }

    func getItems() async throws -> [Item] {
        let url = self.documentsDirectory
            .appendingPathComponent("items.json")
        let data = try Data(contentsOf: url)
        return try JSONDecoder().decode([Item].self, from: data)
    }

    func saveItems(_ items: [Item]) async throws {
        let url = self.documentsDirectory
            .appendingPathComponent("items.json")
        let data = try JSONEncoder().encode(items)
        try data.write(to: url, options: .atomic)
    }
}

The actor keyword gives you serialised access for free — no locks, no dispatch queues, no race conditions. Every read and write goes through the actor's mailbox. For an app where one person is logging purchases at a market stall, this is more than enough.

Why not CoreData or SQLite from the start? Because JSON files are debuggable. I can AirDrop the file off the phone, open it in any text editor, and see exactly what's stored. When you're a solo developer building your first iOS app (I'm a Python developer by day), that debuggability saves hours.

(The app has since migrated to GRDB/SQLite for performance with larger datasets, but the actor pattern stayed — DatabaseStore is still an actor with the same public API.)

Decision 2: Google Drive as dumb storage

Users want their photos backed up and their data exportable. The obvious answer is "build a backend." But a backend means servers, and servers mean monthly costs that I'd need to pass to the user.

Instead, FlipperHelper uses the user's own Google Drive. The OAuth scope is deliberately narrow:

https://www.googleapis.com/auth/drive.file

This is the drive.file scope — the app can only see files it created, not the user's existing Drive files. This matters for trust (users can verify it) and made the Google OAuth review process straightforward.

Images upload to a FlipperHelper_App/images/ folder on Drive. The app creates the folder structure on first sync and caches the folder IDs locally.

Decision 3: CSV-to-Sheets without the Sheets API

Users want spreadsheets. The Google Sheets API requires its own OAuth scope, its own API enablement, and its own quota management. That's a lot of complexity for "export my 200 items to a spreadsheet."

The trick: upload CSV to Drive with the spreadsheet MIME type, and Drive converts it automatically.

func createSpreadsheetFromCSV(
    csvData: Data,
    fileName: String
) async throws -> (fileId: String, url: String) {
    let metadata: [String: Any] = [
        "name": fileName,
        "mimeType": "application/vnd.google-apps.spreadsheet",
    ]

    // Multipart upload: JSON metadata + CSV body
    // Drive sees the target mimeType and converts automatically
    let url = URL(string:
        "https://www.googleapis.com/upload/drive/v3/files"
        + "?uploadType=multipart&fields=id,webViewLink")!

    // ... build multipart body, POST with Bearer token
}

No Sheets API calls, no extra OAuth scope, no formatting code. The user gets a Google Sheet they can open, sort, filter, and share. Done.

Decision 4: Background image sync with BGTaskScheduler

Photos are the heaviest data. A reseller might photograph 30 items in a morning — that's maybe 100MB of images that need to reach Drive eventually, but definitely not over cellular at a car boot sale.

The app queues images locally and syncs them in the background using BGTaskScheduler:

// Registration at app launch
BGTaskScheduler.shared.register(
    forTaskWithIdentifier: "com.oprudnikov.flipperhelper.sync",
    using: nil
) { task in
    guard let bgTask = task as? BGProcessingTask else { return }
    Task {
        await SyncQueueService.shared.processQueue()
        bgTask.setTaskCompleted(success: true)
    }
}

// Schedule when the app backgrounds
func scheduleSync() {
    let request = BGProcessingTaskRequest(
        identifier: "com.oprudnikov.flipperhelper.sync"
    )
    request.requiresNetworkConnectivity = true
    request.requiresExternalPower = false
    try? BGTaskScheduler.shared.submit(request)
}

The SyncQueueService keeps a local queue of pending uploads. Each image gets uploaded, and on success, the queue entry is removed. If the upload fails (no network, token expired), it stays in the queue for the next background execution. The user never sees a loading spinner for photo sync — it just happens.

The tradeoffs

What I give up with this architecture:

No real-time multi-device sync. One phone, one source of truth. If Valentina and I both wanted to edit inventory simultaneously, this wouldn't work. For a single reseller at a market stall, it's fine.
No server-side analytics. I can't see aggregate usage patterns. I rely on App Store analytics and direct user feedback.
Drive quotas. Google Drive gives 15GB free. With compressed images, that's thousands of item photos before anyone hits the limit, but it's a ceiling.

What I gain:

$0/month infrastructure. The only cost is the $99/year Apple developer fee. No Firebase bill, no AWS bill, no database hosting.
Works at 7am in a muddy field. Every feature works offline. Network is a nice-to-have for backup, not a requirement.
Trust. Users see exactly one OAuth permission (drive.file), and it does exactly what it says.
A paid tier that adds value, not ransoms. When I add eBay API integration (planned), users will pay for a genuine new capability — cross-listing from the app — not for the privilege of keeping their own data.

The punchline

I didn't set out to build an "offline-first app with a serverless architecture." I set out to build something my wife could use at a car boot sale without phone signal and without paying a monthly fee. The constraints from that one real user — the person standing next to me while I was coding — produced architecture that I'd now argue is better than what any design review would have produced.

50 App Store downloads, 25 TestFlight users, built solo in 43 days. It's small. But it works in a muddy field at 7am, and that's the spec.

FlipperHelper — free to download on the App Store. Landing page: grommash9.github.io/flipper_helper_pages

How I Got Free User Research by Scraping 2,000 Reddit Posts Before Building

Oleksandr Prudnikov — Wed, 15 Apr 2026 08:54:18 +0000

My user research wasn't a survey. It was a Python script.

Before writing a single line of Swift for FlipperHelper (an iOS app for resellers to track purchases, expenses, and profits), I scraped roughly 2,000 top posts from reseller subreddits — r/Flipping, r/FlippingUK, r/ThriftStoreHauls, and about 20 others. The goal: find out what people who buy and sell second-hand goods actually complain about, ask for, and obsess over.

I'm a senior Python developer by day. My wife Valentina resells clothes and household items — around £1,300-1,900/month in turnover. I watched her track everything in Notes app entries and mental math. I wanted to build something better, but "something better" is a dangerously vague starting point.

So instead of guessing features, I let the data decide.

Why Reddit and not surveys?

Surveys have a problem: people tell you what they think you want to hear. Interviews are better but expensive and slow when you have zero audience and zero budget.

Reddit is different. People on reseller subs aren't performing for a researcher. They're venting, celebrating wins, asking genuine questions, and arguing about what works. A post titled "entry fees are killing my margins" tells you more than a survey checkbox ever could.

The total dataset ended up at around 36,000 posts from 24+ subreddits. The most useful subset was about 2,000 top-scoring posts from the most active reseller communities. High-scoring posts surface topics that resonate with the most people — a built-in signal filter.

The scraping setup

Straightforward Python with PRAW (Python Reddit API Wrapper). Pull posts, filter by top of all time and top of the year, save to CSV and JSON.

import praw

reddit = praw.Reddit(
    client_id="YOUR_CLIENT_ID",
    client_secret="YOUR_CLIENT_SECRET",
    user_agent="research-scraper"
)

subreddits = [
    "Flipping", "FlippingUK", "ThriftStoreHauls",
    "Depop", "Vinted", "EtsySellers", "Ebay"
]

for sub_name in subreddits:
    subreddit = reddit.subreddit(sub_name)
    for post in subreddit.top(time_filter="all", limit=500):
        save_post({
            "subreddit": sub_name,
            "title": post.title,
            "body": post.selftext,
            "score": post.score,
            "comments": post.num_comments,
            "created": post.created_utc
        })

Nothing fancy. The value wasn't in the scraping — it was in reading the output and finding patterns.

What the data revealed: 4 features I wouldn't have prioritised otherwise

1. Multi-currency support

UK resellers on r/FlippingUK regularly talked about buying at French vide-greniers and European flea markets. They pay in euros, sell in pounds. Some buy from US wholesale lots priced in dollars. Not an edge case — a regular part of how many resellers operate. My wife does exactly this: buys at French markets in EUR, sells on Vinted in GBP.

2. Expense tracking (entry fees + transport)

The phrase "entry fees" came up constantly. Car boot sales in the UK charge £1-5 for buyers, more for early bird access. People wanted to know: is this market actually profitable after the entry fee and petrol? FlipperHelper tracks entry fees per market and transport costs so you see real profit per trip.

3. Days to sell

Reseller communities obsess over velocity. "How long did that take to sell?" appears in almost every haul post. Slow-moving stock ties up money and space. FlipperHelper calculates days-to-sell automatically from purchase date to sale date.

4. Multi-platform tracking (16+ services)

Nobody sells on just one platform. The same person lists on eBay, Vinted, Depop, Facebook Marketplace, Etsy, and Grailed simultaneously. Posts about "where should I list this?" were everywhere. FlipperHelper lets you tag items with any combination of platforms and see which one generates the most sales for your inventory type.

Validation vs. discovery

Some features I would have built anyway — expense tracking felt obvious. But multi-currency in v1? I wouldn't have prioritised that without the data. Days-to-sell as a prominent metric? That came entirely from the frequency of "how long did it take to sell" in post comments.

The scraping didn't just validate assumptions. It corrected some and added features I'd never have considered.

What I'd do differently

Scrape comments, not just posts. Comments are where the real detail lives — the "yes, but I also need X" replies that surface secondary features. I only scraped post data initially and had to read comments manually for promising threads.
Tag by sentiment earlier. Knowing "entry fees" appears often is useful. Knowing it appears in a negative context is much more useful — it tells you this is a pain point, not just a topic.
Cluster by user type. A full-time eBay seller and a weekend car boot reseller have different needs. Segmenting posts by user context would have helped prioritise features for the right audience.

The result

FlipperHelper launched in February 2026. Built solo in 43 days. As of mid-April: around 50 App Store downloads, 25 TestFlight users, 3 people who gave detailed feature feedback. Organic downloads started around 12 April without paid promotion.

Small numbers, but every feature traces back to something real people said in real conversations. No guessing, no focus groups. Just a parser and a lot of reading.

I'm the developer, so the obvious plug — but the method stands regardless of whether you use my app or build your own. Your target users are already talking in public. You just need to listen systematically.

FlipperHelper — App Store | GitHub Pages

How I Synced 100K Items from an iOS App Using CSV & GZIP (No Backend)

Oleksandr Prudnikov — Mon, 06 Apr 2026 21:35:00 +0000

I'm building an iOS inventory tracker. Users add items at markets — often with no mobile signal — and want to see everything in a spreadsheet on their laptop later. The app needed to be offline-first and the sync needed to just work.

The problem with Google Sheets API

My first approach: use the Sheets API to update individual cells as users make changes. User taps a price, queue the cell update, sync when online.

Two problems killed this.

Queueing was fragile. When a user toggles a field quickly — yes, no, no, yes, no — the queue needs to reflect the final state, not deduplicate away intermediate changes. I hit a bug where deduplication logic was collapsing the queue incorrectly, sending stale values. Fixing it properly meant building a mini sync engine for what is essentially a data export.

Google's permission model. The Sheets API has no restricted scope. If your app can read one spreadsheet, it can read every spreadsheet on the user's account. The OAuth consent screen would say "allow this app to read and edit ALL your spreadsheets." That's a terrible first impression.

To get this scope approved, Google requires video verification — record a demo, explain why you need access, wait for manual review. I had users on a waitlist. Spending weeks on Google verification while they lose interest was not an option.

The CSV-to-Drive approach

Instead of updating cells one by one, I upload the entire inventory as a single CSV file to Google Drive. The trick: set the MIME type to application/vnd.google-apps.spreadsheet and Google converts it into a Sheets document automatically.

The Google Drive drive.file scope only allows your app to access files it created — it cannot touch anything else on the user's Drive. This scope is auto-approved with no verification required. No video demo, no waiting, no scary consent screen.

From the user's perspective nothing changed. They get a spreadsheet link, open it, see all their items with prices and calculations. They don't care that it's a CSV behind the scenes.

The file size problem and GZIP

I stress-tested the app with 100,000 inventory items. The CSV was huge. Each row implicitly carries the weight of column headers, commas, and quotes. Uploading this over mobile every time the user closes the app was not going to work.

At a previous job I'd seen microservices communicate with Content-Encoding: gzip headers — compressed traffic between APIs to reduce latency. I knew the concept but hadn't applied it to file uploads.

Before GZIP, I spent time manually optimising the CSV — truncating column headers, stripping null values, omitting trailing empty fields. Google Drive supports all of this. But once I added GZIP encoding, all of that manual work became pointless. GZIP gave approximately 20x compression. The algorithm handles repetitive text patterns (which CSV is full of) far better than any manual optimisation.

Swift has built-in GZIP support through the Compression framework, so implementation was minimal — compress the data, add the content encoding header, upload.

Fitting sync into iOS background tasks

iOS is strict about background work. Two main options:

BGProcessingTask — runs overnight when charging. Timing is unpredictable, might not run if battery is low
beginBackgroundTask — gives ~30 seconds when the user closes the app

I went with the 30-second window. When the user closes the app, it builds the CSV, compresses with GZIP, compares against the last uploaded version, and uploads if needed. 100,000 items sync comfortably within the limit.

The comparison is simple: keep a hash of the last successfully uploaded CSV. On app close, build new CSV, hash it, compare. Same hash = no upload needed. Different = compress and upload.

Same sync triggers on app launch too, so data stays current from both directions.

Photos are handled separately

Inventory photos follow a different path. Each photo is compressed using iOS built-in image processing (~10x size reduction) and queued for upload individually. The queue processes photos progressively — on launch, close, and in the background.

If a user adds 50 photos at once, they upload gradually. Photos go to Google Drive alongside the CSV, under the same drive.file scope.

The architecture that emerged

What started as a shortcut turned into something genuinely simpler and more robust:

Offline-first — all data lives on the phone. Works with no internet, which matters at outdoor markets
No backend — zero infrastructure, zero running costs. Google Drive is the only dependency and it's the user's own storage
Auto-approved permissions — drive.file scope means no Google verification, no scary consent screens
Sync is a view, not a source of truth — the spreadsheet is an export. If it breaks, phone data is safe. No sync conflicts
Optional — originally required Google sign-in. Now sync is entirely optional

Is this permanent? Probably not at scale. But 100,000 items holds up under stress testing. That's years of headroom. By the time it's outgrown, it'll be clear whether building something more complex is worth it.

Key takeaway

I usually try to make the technical solution perfect before moving on. This time I had users waiting and couldn't afford to. The shortcut turned out to be better than the "proper" approach would have been — simpler permissions, no backend costs, works offline, syncs fast.

Sometimes the temporary workaround is the architecture. The trick is knowing when to stop optimising and ship.

I built an offline-first iOS app in 43 days with Swift, SQLite, and Claude Code

Oleksandr Prudnikov — Fri, 03 Apr 2026 05:10:08 +0000

My wife buys secondhand items at flea markets and car boot sales in the UK and resells them on eBay and Vinted. She was tracking everything in Google Sheets and kept forgetting what she paid for things. When someone sent an offer she had no idea if it was a good deal.

So I built her an iOS app. That was 43 days ago. It's now on the App Store, completely free, and a few people are actually using it. Here's how I built it and the technical decisions along the way.

What the app does

You take a photo at the market, enter the price, and the app tracks the item through its lifecycle: purchased → listed on platforms → sold. It calculates profit after all expenses — entry fees, transport, packaging. Supports 4 currencies with automatic exchange rates. Works completely offline.

Tech stack

Swift + SwiftUI — iOS 17+
SQLite via GRDB — local storage with WAL mode, foreign keys, composite indexes
Google Drive API — optional photo sync + CSV export (drive.file scope only)
BGTaskScheduler — background photo uploads
CoreLocation — auto-suggest nearby markets
No backend — everything runs on device, zero server costs

The architecture

SwiftUI Views
    ↓
ViewModels (ObservableObject)
    ↓
Services (GoogleAuth, Export, Location, Notification)
    ↓
DatabaseStore (Swift Actor — all CRUD operations)
    ↓
SQLite (GRDB, WAL mode) + Local Images

The key decision was making it offline-first. Car boot sales happen in fields with no signal. The app can't depend on network for anything core. Google Drive sync is purely optional — you can use the app forever without ever connecting a Google account.

Day 1–7: JSON files and regret

I started with the simplest possible storage — JSON files in the Documents directory. One file per entity type (items, markets, sellers, expenses). Read the whole file into memory, modify, write it back.

This worked fine for 20 items. It did not work fine for 200 items. Loading the entire items array into memory on every read was getting slow, and there was no way to do efficient queries like "show me all unsold items sorted by date, paginated."

Day 18: The SQLite migration

I migrated everything to GRDB (a Swift SQLite wrapper). This was the most significant single-day change in the project.

GRDB gives you:

Typed record structs that map to tables
A migration system (versioned schema changes)
WAL mode for concurrent reads
Proper indexes for fast queries

My migration system has 4 versions so far:

// v1: Initial schema — all tables, indexes, foreign keys
// v2: Composite indexes for paginated list queries
// v3: Crockford Base32 SKU regeneration
// v5: Market "askForEntryFee" boolean column

The paginated queries went from "load everything into memory and filter" to actual SQL with LIMIT/OFFSET on indexed columns. Night and day difference.

Offline-first with optional Google sync

The sync model is simple. Items default to "local" status. If you connect Google Drive:

Photos queue for upload via SyncQueueService
BGTaskScheduler processes the queue even when app is suspended
CSV export runs on a 5-minute timer — compares MAX(updatedAt) vs last sync timestamp, only uploads if data changed
CSV is gzip-compressed before upload
Google auto-converts the CSV to a Google Sheet (no Sheets API needed)

I deliberately avoided the Sheets API. Using only drive.file scope means the app can only access files it created itself. Better privacy, simpler OAuth, fewer permissions to explain to users.

Multi-currency with exchange rates

My wife buys in GBP at UK markets but sometimes sells in EUR or USD on eBay. The app needs to show profit in your home currency regardless of what currencies you bought and sold in.

I fetch daily rates from a free API and cache 365 days of history locally in SQLite. For conversions I support three paths:

Direct rate — GBP → USD
Reverse rate — USD → GBP (1/rate)
Cross rate via common base — EUR → CAD via USD

If you're offline for days the app uses cached rates and shows a warning that they might be stale. You can refresh manually when you get signal.

SKU generation

Every item gets a unique SKU like FH-20D6G0NR. I use Crockford Base32 encoding — uppercase only, no ambiguous characters (I, L, O, U are excluded). The SKU is time-based with an atomic counter for guaranteed uniqueness.

Users can copy the SKU and paste it into their eBay/Vinted listing descriptions, then match up sales later.

Building with Claude Code

I used Claude Code throughout the entire build. It's genuinely how I shipped this in 43 days as a solo developer. The AI handled a lot of the boilerplate — GRDB record types, SwiftUI form layouts, CSV generation, the Google OAuth flow.

Where it helped most was the migration from JSON to SQLite. I could describe the existing data model and the target schema and Claude Code would generate the migration code, the new record types, and update all the queries.

Where it didn't help: design decisions. What should be offline vs synced, how to handle currency conversion edge cases, which features actually matter for my wife's workflow. Those are product decisions that need human context.

The Figma redesign (Day 23)

I'm not a designer but I knew the app looked like a developer built it. So I created a proper design system in Figma first:

Font: Roboto Flex (variable weight)
Design tokens: gold #F9DDA5, badge #BBCBF7, card bg #F8FAFB, accent #334B90
Neumorphic shadows: two styles — large (radius 30) and small (radius 15)
Light mode only: explicit colors everywhere, no system adaptive

Then rebuilt every screen to match the Figma exactly. The 1:1 Figma px → iOS pt mapping made this surprisingly straightforward.

What I'd do differently

Start with SQLite from day one. The JSON-to-SQLite migration was worth it but I lost time building something I knew I'd throw away. If your app will have more than ~50 records, just use a database from the start.

Add search earlier. Users asked for it immediately. Being able to find an item by title or SKU across all tabs seems obvious in hindsight.

Don't overthink Google integration. I spent too long trying to make the sync perfect. The simpler approach — CSV upload with change detection — works well and is much easier to maintain than real-time sync.

Current state

~18,100 lines of Swift across 69 source files
16 selling platforms supported
4 currencies with daily exchange rates
4 database migrations
8-page onboarding walkthrough
Free on the App Store, no ads

The whole thing runs with zero server costs. GitHub Pages for the website, GitHub Actions for CI/CD, Apple Developer account for distribution. That's it.

If you're curious:

App Store: FlipperHelper
Website: flipperhelper
Blog: guides for resellers

Happy to answer questions about the architecture, the GRDB setup, or the Claude Code workflow.