AI-Assisted Mobile App Development: What a Solo Founder Learned Building Pollcy

AI-assisted mobile app development makes it possible for a capable solo builder to go from concept to a working app in days. But the story of Pollcy, a news-and-polling app built with React Native, Firebase, and Cursor, is a useful reminder that generating a promising demo is not the same thing as building a product, operating it safely, or finding a repeatable way to acquire users.

The original account, posted to r/SaaS by Pollcy’s builder after roughly 1.5 years of work, is especially valuable because it does not frame AI coding as magic. It describes a more realistic progression: rapid early momentum, declining confidence in an AI-shaped codebase, a reset around documentation and data models, then a harder lesson about infrastructure costs and marketing. The central takeaway is simple: AI can accelerate implementation, but the founder still has to own the system.

The Pollcy story: a fast prototype meets the realities of product building

Pollcy began with a straightforward product premise. The app surfaces controversial daily news, provides summaries, asks users a question, and lets them vote between predefined options. It is a format designed around reaction, opinion, and repeat engagement rather than a one-time utility.

For the technical stack, the founder chose React Native for one codebase across iOS and Android, Firebase for backend services, and a monorepo that kept the mobile application and Firebase-related code in the same workspace. That is a rational early-stage setup. React Native is explicitly designed to let teams build native apps for Android and iOS with React, while Firebase reduces the amount of backend plumbing a small team needs to own. (reactnative.dev)

The first demo reportedly arrived in about a week. Friends and family were enthusiastic, which is a familiar and dangerous early signal for founders: it confirms that an app can be made and that people close to you understand the premise. It does not confirm that strangers will install it, understand the value quickly, return tomorrow, or tell anyone else.

That distinction matters because Pollcy’s later problems were not primarily about whether React Native, Firebase, or Cursor could produce a working application. They were about trust in the codebase, predictable operations, and a compelling distribution loop. Those are separate jobs, and treating them as one is how an impressive prototype becomes a fragile product.

AI-assisted mobile app development changes the bottleneck, not the responsibility

The founder initially used Cursor in short sessions to build small features. This worked until it did not. When the agent lacked durable context, it could duplicate logic, overwrite code outside the immediate task, or break an existing behavior while completing a requested change.

That is not evidence that coding agents are uniquely unreliable. It is evidence that software systems have architecture, invariants, and history that are not automatically visible in a single prompt. Cursor’s own documentation explains why persistent rules exist: language models do not retain memory between completions, so project rules and AGENTS.md files provide reusable context at the start of an agent interaction. (cursor.com)

The important reframing is this:

• AI reduces the cost of producing a change.
• It does not eliminate the cost of specifying the right change.
• It does not verify that the change preserves business rules.
• It does not decide which risks are acceptable in production.
• It does not create a reason for customers to care.

For a solo founder, this is actually good news. The goal is not to become slower by manually reviewing every mundane line of code. The goal is to move human attention to the highest-leverage decisions: product boundaries, data contracts, authorization, metrics, release quality, and customer learning.

A useful mental model is that an AI agent is a high-speed contributor with incomplete organizational memory. Give it a precise ticket, scoped files, tests, acceptance criteria, and architectural constraints, and it can be extremely productive. Ask it to “improve the voting experience” in a poorly documented repository, and it may create a plausible local solution that damages the global system.

The biggest lesson: documentation is the control plane

The strongest part of the Pollcy founder’s retrospective is not the use of Cursor or Firebase. It is the decision to write project documentation manually and treat it as the source of truth.

The founder documented what the app is, how its modules work, and—most importantly—the data structures at each Firestore database path. They also made the TypeScript mobile client and Python Firebase functions conform to that shared model. A commenter called the Firestore data-model document the “real lesson,” noting that type definitions and actual Firestore documents can slowly diverge until a deployment exposes the mismatch.

That observation is exactly right. Firestore is document-oriented: data lives in documents organized into collections and subcollections rather than fixed relational tables. That flexibility speeds iteration, but it also means application-level discipline must enforce schema expectations, query assumptions, and ownership rules. (firebase.google.com)

What a useful source-of-truth document should include

A good product-and-data specification is not a vague overview. It should make decisions visible enough that a developer, a future teammate, or an AI agent can distinguish an intended change from an accidental one.

For a polling app, the document should cover at least:

1. Domain vocabulary. Define a poll, news item, vote, user profile, moderation state, category, publication date, and result snapshot. If two terms are close but different, say so.
2. Firestore paths and document shapes. Document paths such as polls/{pollId}, users/{userId}, polls/{pollId}/votes/{userId}, and any aggregated result records. Include required fields, optional fields, field types, ownership, and indexes.
3. Read and write flows. Explain what happens when a user opens the feed, reads a poll, submits a vote, changes a vote, reports content, or returns after a long absence.
4. Business invariants. Examples: one vote per signed-in user per poll; a closed poll cannot accept votes; only server-side code can change aggregate totals; summaries cannot be edited after publication without an audit trail.
5. Authorization rules. State who can read, create, update, and delete each resource. Write this alongside the security-rule implementation, not after it.
6. Failure behavior. Define the UI and retry behavior for an expired session, unavailable network, duplicate submission, stale result count, or failed function.
7. Cost assumptions. List expected reads and writes for a feed impression, poll view, successful vote, and notification-triggered return.

The manual-writing part also has a hidden benefit. When the founder said they implemented models by hand because it let them simulate the full system mentally, they described an important form of design review. Typing a model forces decisions about nullability, state transitions, defaults, backwards compatibility, and ownership. AI can help draft or validate those models, but it should not be the only entity that understands them.

Documentation should constrain agents, not merely inform people

A README that agents never see is useful but insufficient. The Pollcy workflow used AGENTS.md and Cursor rules to direct the agent toward the Markdown documentation and to prevent it from editing that source of truth without explicit permission. That is a practical governance pattern.

Your agent instructions should be specific about behavior. For example:

• Read docs/product.md and docs/data-model.md before modifying database access.
• Never add a Firestore field or collection without updating the data-model document.
• Do not bypass repository functions with direct SDK calls.
• Do not alter authorization rules without adding emulator tests.
• Prefer existing model types and serializers over new parallel types.
• Stop and ask for clarification when a requested behavior conflicts with an invariant.

This turns documentation from passive reference material into an operational contract. It also protects the founder from the long-term cost of re-explaining the application in every chat session.

Why a monorepo helps, and where it can still fail

Keeping the React Native client and Firebase functions together made sense for Pollcy because both sides depended on shared product decisions. A monorepo can make changes easier to review because mobile UI, function logic, model definitions, rules, scripts, and docs evolve in the same pull request.

For a small app, the chief advantage is not fashion or tooling sophistication. It is change visibility. If a poll document gains a field, the affected client type, Cloud Function, security rule, migration plan, test fixture, and documentation should be easy to find together.

But a monorepo does not automatically prevent coupling. It can become one large workspace full of accidental direct imports, duplicated types, and scripts nobody trusts. The remedy is clear boundaries:

• Put shared domain types and validation schemas in an intentionally named package.
• Keep client-only UI concerns separate from server-side administration code.
• Centralize data access behind repositories or service modules.
• Make production deployment commands explicit and reviewable.
• Avoid sharing code merely because two packages happen to use the same language.

In Pollcy’s case, the best shared asset may not be a TypeScript package at all. It may be the written data model that Python functions and TypeScript clients both implement independently. Shared documentation is sometimes safer than shared runtime code because it reduces language-specific coupling while preserving a common contract.

Firebase cost observability: count more than visible client calls

Another practical idea from the post was wrapping Firebase calls with custom counters to estimate the database cost of a user session. This is excellent founder behavior. A product cannot make intelligent tradeoffs if its unit economics are invisible.

For Firestore, usage is not limited to an obvious getDoc() call in the app. Billing can include document reads, writes, deletes, index-entry reads, storage, and bandwidth. Reads from queries and real-time listeners count too, and security-rule evaluation can add read charges in some cases. (firebase.google.com)

The community reaction added an important caveat: a client-side counter can undercount in the exact direction that eventually shows up on the bill. It sees the activity inside a user session. It may miss or poorly attribute scheduled jobs that ingest and process daily news, server-side fan-out work, administrative tooling, retries, background listeners, and function-driven reads.

Build a cost ledger, not just a session counter

A better approach is to define an event taxonomy across the entire system. Every meaningful database action should be attributable to a feature and execution environment.

Then report three numbers every week: cost per active user, cost per meaningful action, and total non-user-driven operations. The third figure is vital. A startup can have low session cost and still accumulate a surprising bill because automation, cron-like functions, or poor listener hygiene run continuously.

Firestore’s pricing documentation also makes clear that realtime listeners incur reads when documents in the result set are added or updated, and reconnection behavior can affect billing depending on persistence and disconnect duration. (firebase.google.com) For a polling product, that means a “live result” screen should be a product decision, not a default technical flourish. Do users truly need vote totals to animate in real time, or is a refresh-on-return experience sufficient for most screens?

Design the UI to avoid waste without adding friction

The Pollcy founder noted that thoughtful UI choices can cut database use without making the experience feel worse. That is a powerful principle.

For example, a feed can show a compact result snapshot stored on the poll document rather than querying every vote. A user can submit a vote through a server-controlled path that atomically updates the canonical vote and aggregate. A detail page can fetch comments only when the user opens that section. A results screen can use a short-lived refresh interval or explicit refresh instead of a permanent listener.

The key is to distinguish freshness that creates value from freshness that merely looks technically impressive. In a consumer social product, live activity can support excitement. In a low-traffic early-stage app, it can expose emptiness while raising cost. Product maturity should determine the architecture, not the other way around.

Development and production projects are a sensible minimum

Pollcy used separate Firebase projects for development and production, allowing the founder to deploy a feature to a development environment, install a debug build, and test it on a real device before shipping. That separation is one of the most practical safeguards a solo mobile founder can adopt.

A development environment gives you permission to test destructive migrations, malformed documents, failure states, and experimental rules without corrupting real user data. It also prevents test push notifications, test accounts, and accidental scripts from affecting production users.

Firebase’s Local Emulator Suite adds another layer before a shared development project. It supports local prototyping, can be configured with Security Rules definitions, and can be integrated into CI workflows. Firebase also documents using the Firestore emulator to inspect Security Rules activity during testing. (firebase.google.com)

A durable release ladder looks like this:

1. Local emulator: validate rules, functions, test fixtures, and unhappy paths quickly.
2. Development project: test the real mobile build, backend integration, configuration, and device behavior.
3. Internal or beta distribution: test release signing, app-store-like build behavior, analytics, and upgrade paths.
4. Production: release gradually, monitor errors and usage, and retain a rollback plan.

The important nuance is that “dev versus prod” should not become an excuse to skip automated checks. A debug build on the founder’s phone is valuable because mobile behavior is hard to simulate. It is not enough for vote integrity, permission enforcement, or data migrations. Those need repeatable tests.

Polling apps have a trust problem, not only a technical problem

A controversial-news polling app is more complicated than a simple content feed because the core interaction invites disagreement. That can be the product’s advantage, but it also creates risks around manipulation, brigading, misinformation, harassment, and user distrust.

The product must answer questions that are both technical and editorial:

• Who selects the stories and frames the questions?
• Are summaries linked to multiple reputable sources or generated from one source?
• Can users see methodology, timestamps, and corrections?
• Is one person allowed one vote, and what does that claim really mean?
• What happens when a poll question is loaded, misleading, or overtaken by events?
• Are results shown before voting, and how does that influence behavior?

The infrastructure should reinforce the product’s stated rules. Do not let the mobile client write aggregate results directly. Protect sensitive write paths through backend logic, validate user identity and abuse signals, rate-limit actions where needed, and log moderation decisions. Firebase App Check is one relevant defense: its platform providers can help ensure requests to Firebase resources originate from the legitimate app, although it is not a complete anti-fraud solution by itself. (firebase.google.com)

This is also where the data-model document pays off again. “Vote” is not just a document with a user ID and an option. It is a stateful event with eligibility, idempotency, visibility, correction, and aggregate-consistency requirements. If those are not documented, AI-generated implementation can make a voting flow look correct while leaving important integrity gaps.

The community’s marketing critique is the other half of the story

The most pointed comment on the original post focused on acquisition. According to the commenter, two $100 campaigns produced zero users, not because the app lacked creativity but because a screenshot of a feed gave people no compelling reason to tap. Their recommendation was sharper creative: run an ad centered on a single divisive poll with the vote split visible, then make the click necessary to discover how the debate resolved.

Whether that exact ad works is an empirical question. But the diagnosis is strategically sound: Pollcy’s product loop is not “read a news feed.” It is “encounter a question, form an opinion, see social disagreement, and participate.” Ads should sell the moment of tension, not the app’s generic interface.

A better acquisition hypothesis for Pollcy

A founder should turn that comment into a testable funnel rather than a one-off creative idea.

Ad promise: Present one timely, comprehensible, emotionally charged question. Avoid vague statements such as “Stay informed with balanced news polls.”

Landing or store-page proof: Show the exact interaction: question, opposing answer options, current split, and a concise explanation of what users get after voting.

Activation event: Do not define activation as an install. Define it as a user who completes onboarding, reads one poll, votes, and returns to see results or another poll.

Retention hook: Give users a clear reason to return: new daily questions, results of prior votes, topic follows, or alerts when their opinion falls into a minority or majority.

Measurement: Track impressions, thumb-stop or video-view rate, click-through rate, store-page conversion, install rate, first-vote completion, day-one return, and cost per activated voter.

This matters because paying for installs before proving activation is a form of expensive self-deception. If people click the ad but do not install, the positioning or store page may be weak. If they install but do not vote, onboarding or the first poll may be weak. If they vote once but never return, the product lacks a durable habit loop.

What founders should copy—and what they should avoid

The Pollcy experience offers a useful checklist for anyone building an AI-assisted consumer app.

Copy these practices

• Use a cross-platform stack when speed and shared product iteration matter more than platform-specific novelty.
• Keep client and backend work visible in one repository when a small team benefits from coordinated changes.
• Write product, architecture, and data-model documentation in your own words before asking an agent to make broad changes.
• Use persistent agent rules to point coding tools at canonical documentation.
• Separate local, development, and production environments.
• Measure actual database activity and translate it into unit economics.
• Test marketing messages around the core emotional or functional loop, not generic screenshots.

Avoid these traps

• Treating a friends-and-family demo as market validation.
• Using AI-generated code that nobody can explain, test, or safely modify.
• Defining database schemas only through scattered client types and function code.
• Counting only client-visible database calls when estimating cloud costs.
• Adding real-time listeners because Firebase makes them easy rather than because users need them.
• Spending on acquisition before the activation and retention journey is instrumented.
• Mistaking technically balanced content for a compelling consumer proposition.

A practical operating system for AI-built mobile apps

The larger lesson is that AI-assisted mobile app development needs an operating system. It is not enough to have a prompt workflow. You need a set of artifacts and rituals that make fast change safe.

Start each feature with a one-page brief: customer problem, scope, non-goals, affected data, analytics events, failure states, security implications, test plan, and release criteria. Ask the agent to produce a plan before code. Require it to identify which documentation it read and which files it expects to change.

During implementation, keep changes small and reviewable. Run type checks, unit tests, emulator tests, and device checks. For sensitive backend operations, test both authorized and unauthorized behavior. When a feature reaches development, inspect its actual database reads and writes rather than relying on estimates.

After release, review three dashboards: product behavior, system reliability, and cost. Product behavior tells you whether users reached value. Reliability tells you whether the experience held up. Cost tells you whether success would be economically viable. A feature is not truly done until all three are understood.

Conclusion: the founder must remain the system designer

Pollcy’s journey is encouraging precisely because it is not a simplistic success story. A software engineer new to mobile development used modern tools to make an app quickly, then recognized the limits of speed without understanding. The corrective actions—manual documentation, a canonical Firestore model, persistent agent instructions, environment separation, scripts, and usage tracking—are the practices that turn AI output into maintainable software.

The community feedback adds the equally important commercial lesson. A product built around debate must market the debate. If the ad shows only a generic feed, it hides the reason someone would open the app. If it shows an unresolved question and social tension, it begins to express the actual loop.

For founders and builders, the standard should not be “Can an agent make this?” It should be: “Can I explain the system, measure its economics, protect its users, safely change it next month, and communicate why a stranger should care today?” AI can dramatically shorten the path to that answer. It cannot answer it for you.

FAQ

What is AI-assisted mobile app development?

AI-assisted mobile app development is the use of coding agents and generative AI tools to help plan, write, refactor, test, document, and debug mobile software. It works best when humans provide clear architecture, requirements, tests, and review rather than treating the tool as an autonomous product team.

Is React Native a good choice for a solo mobile app founder?

It can be. React Native lets builders use React to create apps for Android and iOS, which can reduce duplicated work for teams that do not need deeply platform-specific experiences on day one. (reactnative.dev) The tradeoff is that mobile release processes, native dependencies, performance work, and platform differences still require attention.

Why should a Firestore app have a written data model?

Firestore gives teams flexibility because its database is document-oriented, but that flexibility makes model drift easier. A written data model aligns client types, backend functions, security rules, indexes, migrations, analytics, and AI-agent instructions around the same contract. (firebase.google.com)

Do client-side Firebase counters accurately predict Firestore costs?

They are useful but incomplete. Client counters can estimate per-session usage, but Firestore bills for more than visible client fetches, including queries, listeners, index reads, storage, and some security-rule evaluation. Server-side jobs and background activity also need separate measurement. (firebase.google.com)

What should a polling app test before buying more ads?

Test the full activation loop: whether an ad makes a clear promise, whether a visitor installs, whether they complete a first vote, whether they understand the result, and whether they return for another poll. Optimize for activated and retained voters—not merely low-cost impressions or installs.