If you’d asked us six months ago what the hard part of building a baby-name app would be, we’d have said: building the app.

We were wrong. The work split actually landed roughly like this:

• 50% marketing website and content engine

• 20% backend, sync, partner matching

• 20% fighting the app stores

• 10% building the actual app

That ratio surprised us, and looking back, we don’t think it’s unusual. Consumer mobile in 2026 is mostly the work around the app, not the app itself. This is a post about everything we learned by being honest about that split, plus a few specific decisions we’d make exactly the same way next time, and a few we’d reconsider.

The app in question is Namekin, a privacy-first baby name discovery app we built and launched this month on the App Store and Google Play. It’s free to download, has no account, and stores your name preferences on your device rather than on our servers. The decisions behind those constraints shaped almost everything else.

This is the lesson we genuinely didn’t expect.

A modern consumer app needs a website that does about ten jobs at once. It has to convert organic search traffic into installs. It has to look right on every device. It has to render server-side fast enough for Google to actually crawl it. It has to carry the privacy policy, the support page, the legal pages, and the entire content marketing strategy. It has to handle deep links from social shares. And for an SEO-led acquisition strategy like ours, it has to scale to thousands of pages of meaningful, indexable content.

Namekin’s marketing site at namekin.app ended up with around 10,000 pages: name pages, list pages, comparison pages, blog posts. Each one has to be genuinely useful (Google has got very good at detecting thin programmatic content), each one needs internal links to other pages so the long tail of low-traffic pages gets crawled, and each one needs to load fast enough to rank.

What surprised us:

Indexing isn’t automatic. Submitting a 10,000-page sitemap to Google doesn’t mean you get 10,000 pages indexed. Young domains get rate-limited heavily, and most of the long tail sits in “Discovered, currently not indexed” for months. We learned to split the sitemap into themed sub-sitemaps (blog, lists, names by chunk) using Next.js’s generateSitemaps(), and to use per-row modified_at timestamps so Google’s freshness signal does its job. Indexation hit roughly 92% within three weeks.

Crawl budget is a finite resource. Every URL Google fetches is one it didn’t spend somewhere else. We added a robots.txt block for query-string URLs, a www-to-apex redirect, and a page-warmup step on every new content page so Googlebot doesn’t hit a cold render. Each of these took 30 minutes and moved the needle.

A daily content cadence is the slowest cheap win you can get. Publishing a meaningful blog post and several new name pages every day, for weeks, sends Google a freshness signal that compounds. Most teams won’t do it because the marginal post feels low-value. The marginal post is exactly the point.

The honest accounting: building the website properly takes about as long as building the app, and the ROI per hour is probably higher. We’d budget for it explicitly next time.

The actual writing of the app was the cheapest part of the build. The submission process to both stores was disproportionately expensive.

Some of what we learned the hard way:

The Apple side. Apple’s review is fast (often under 24 hours) but strict. Rejections come for surprising reasons: the contact email needs to actually work; in-app purchases need full descriptions before review will pass; the encryption export compliance question is mandatory and almost everyone gets it wrong the first time (if your app uses any non-exempt cryptography for partner-to-partner data, you tick yes, and you’ll need a self-classification report); screenshots need real content rather than placeholders; the privacy manifest now needs every third-party SDK’s reasons declared accurately. We had two rejection rounds before passing, both for small things we should have caught.

The Google side. Google’s review is slower (three to seven days, sometimes longer) but more forgiving on rejection severity. The painful work is the Data Safety form: every piece of data your app collects, shares, transfers, or processes has to be declared in a long structured questionnaire. For a privacy-first app like Namekin, most answers are “we don’t collect this,” but each “no” still needs to be checked correctly. Google now requires Closed Testing with at least 12 testers for 14 or more days before you can apply for production access. That alone added two weeks to our timeline.

The cross-cutting work. App icons, splash screens, and store listing screenshots have completely different size specifications for iOS, iPadOS, iPhone variants, and Android device sizes. The marketing copy character limits are different on each store. The categorisation taxonomies are different. The age rating questionnaires are different. Almost nothing transfers directly.

If we did this again, we’d treat the submission process as a three-to-four-week project that runs parallel to development, not a one-week task at the end. We’d start the Closed Testing recruitment on Google Play the day the first usable build exists, not the day we want to launch.

The infrastructure stack for a modern consumer mobile app is wider than it used to be. Some of what Namekin uses:

• React Native + Expo for the app itself

• Supabase for partner sync, polls, push notification tokens

• expo-secure-store for partner keys

• RevenueCat for subscription management (planned, not live yet)

• Expo Notifications for push (with APNs HTTP/2 and FCM v1)

• EAS Build + EAS Update for CI and OTA deployments

• Next.js 16 + Vercel for the marketing site

• Supabase (separate project) for the website content database

• Cloudflare for DNS and edge caching of the marketing site

• Vercel Analytics for first-party page-view tracking

• Cloudflare Workers for some edge functions

• An LLM API for some of the content authoring tooling

Each tool earns its place, but the cumulative complexity is significant. Two specific lessons:

Pick the smallest tool that solves your real problem, not the most popular. We considered Firebase, Auth0, Amplify, and a few others. Supabase won for Postgres-first thinking, generous free tier, and the ability to use the same project for partner sync and for the content database via Row Level Security. Familiarity was not the deciding factor.

Some tools become invisible quickly. Some never do. RevenueCat for in-app purchases collapses three months of StoreKit + Play Billing work into one weekend. EAS Update for OTA JavaScript pushes is genuinely transformative: we can fix a typo or a crash in 20 minutes without waiting for store review. On the other hand, push notifications remain stubbornly complicated regardless of which abstraction you reach for. That one we just had to learn the hard way.

This is the section we’d encourage anyone building consumer software in 2026 to think about carefully.

We chose to make Namekin privacy-first from day one. That doesn’t just mean a nice copy block on the homepage. It means a series of architectural constraints that ripple through every technical decision:

Names stay on the device. The full name database (over 9,000 entries, each with meaning, origin, etymology, pronunciation, namesakes) lives in a bundled SQLite file inside the app. No network call required to browse names. The app works fully offline.

Partner sync is end-to-end encrypted. When two partners connect their phones, an X25519 key exchange happens on-device. Subsequent swipe data is encrypted with XSalsa20-Poly1305 before leaving either device, relayed through Supabase as opaque blobs, and decrypted only on the receiving partner’s phone. We cannot read partner sync data, even with full database access.

No analytics on the app. No user IDs, no funnel tracking, no fingerprinting. The only telemetry is a crash reporter, configured to strip request bodies and user IDs.

The marketing site honours the same posture. No cookies set by default. No Google Analytics. No Facebook pixel. Cloudflare’s privacy-friendly Web Analytics for trend data, Vercel Analytics for first-party page views, and the privacy policy describes exactly what each does in plain English.

Privacy as a constraint cost us things. It cost us the easy revenue path of selling anonymised aggregate data. It cost us the simplicity of a normal analytics dashboard. It cost us several feature ideas that would have been useful but would have required us to know things about our users we’d promised not to know.

What it bought us: a marketing story that we can defend honestly, a Privacy Manifest that took 20 minutes to fill out because we genuinely don’t collect anything, a Data Safety form that’s mostly “no” answers, and a brand position that’s increasingly rare for consumer apps.

We’d make this trade-off again without hesitation.

A short note on the part of this we got right.

The architectural decisions that came from the privacy constraint (the on-device SQLite database, the end-to-end partner sync, the minimal analytics posture) feel more correct every week we operate the app. They make the marketing story honest. They make the compliance work cheap. They make the legal pages short. They mean we don’t have to think about data breaches because we don’t have data to breach.

The marketing site at namekin.app is doing the slow compounding work it’s supposed to do, with organic search clicks roughly doubling each week now that indexing has caught up. The app itself is small, focused, and stable. We’re starting to see early signs of partner-matching being the feature people actually share with friends, which was the bet from the beginning.

If you’re building a consumer mobile app in 2026 and want to talk through any of the above, we’re Identity Agency. We’ve made every mistake described here at least once, and we’d be glad to share what we learned in detail.