Build an astrology app with no coding experience

Building a phone app without coding experience is now realistic in a way it was not two years ago. The building is the easy half. The half that catches people is that a mobile app cannot hold an API key safely, and most tutorials skip straight past that.

This guide covers both: how to get an app built and running on your phone, and how to structure it so your key is not sitting inside an app anyone can download and unpack.

The tech stack, and why

• Expo (React Native) — one codebase, runs on both iPhone and Android, and you can see it on your own phone in about a minute by scanning a QR code. No Xcode, no Android Studio to start.
• A small backend — a handful of server routes that hold your API key and pass requests through. Non-negotiable; the next section explains why.
• Occult API — the calculations.
• Claude Code or Cursor with MCP — the assistant, able to read the real API reference while it works.

If you would rather not touch code at all, FlutterFlow is a drag-and-drop alternative that can call an API. It gets you further without code, and gets harder to escape later. Expo with an assistant is the path this guide takes.

The rule that actually matters

Never put your API key in the app. Not in the source, not in an environment file, not obfuscated. A published app can be downloaded and taken apart by anyone, and strings inside it are not secret. This is true of every API key in every mobile app, not just ours.

So the app does not call the API. The app calls your server, and your server calls the API with the key. Three practical benefits beyond the obvious one:

• If the key ever leaks you rotate it in one place, without shipping an app update and waiting for review.
• You can cache. Today's panchang for one city is the same for every user, so it can be calculated once and served many times.
• You can add your own rate limiting, so one misbehaving copy of the app cannot drain your credits.

The server can be tiny — a few routes on Vercel or Railway is plenty. Ask your assistant for "a small API proxy that keeps the key server-side" and it will know what you mean.

Step 1 — key and MCP

Create a key in the dashboard, then connect MCP so the assistant can read the endpoint reference as it builds. One line for Claude Code:

claude mcp add occult-api -e OCCULT_API_KEY=yt_live_your_key_here -- npx -y occult-api-mcp

Other clients use a JSON block — see the setup guide.

Step 2 — build the proxy first

Before the app, ask for the server. Something like:

Create a small Next.js API that proxies to the Occult API. One route per thing I need: panchang, birth chart, festivals. Read the key from OCCULT_API_KEY on the server. Cache each day's panchang so repeat requests do not spend a credit.

Deploy it and note the URL. This is what the app will talk to.

Step 3 — build the app

Create an Expo app with three screens: today's panchang, a birth chart from a form, and a festival list. Fetch everything from <your proxy URL>. No API keys in the app. Make it work on a phone screen.

Run it and scan the QR code with your phone. You will be looking at your own app within a few minutes, and every change you make appears immediately.

Step 4 — the endpoints behind those screens

• /api/astro/panchanga/ — the daily screen.
• /api/astro/chart/ — the chart. Use render: "svg" and display the returned markup rather than drawing a chart yourself; React Native can show an SVG directly.
• /api/astro/monthly_panchang/ — a whole month in one call, which is far better than thirty calls for a calendar screen.
• /api/astro/festival/ — the festival list.

That third one is worth dwelling on. A month view built from thirty separate requests is thirty credits and a slow screen. One call for the month is one credit and instant. Ask your assistant to check whether a range endpoint exists before it writes a loop — that habit is most of the difference between a cheap app and an expensive one.

Step 5 — test on a real phone, on a real date

Check a date you can verify independently, and check it in a timezone other than your own. Mobile apps are where timezone bugs hide, because the phone has its own idea of local time and it may not match the place the user is asking about.

Step 6 — publishing

Expo builds the files the app stores want. Budget real time here: Apple's review is measured in days and rejects vague listings. Google Play is faster. Neither is a coding problem, which is a relief by that point.

What it costs to run

One credit per successful call, failures free. With caching in the proxy, a daily-panchang app serves many users from few calls, because the answer is the same for everyone in the same place on the same day. Without caching you pay per user per open. That one decision matters more than any other to your bill.

Where people get stuck

• Putting the key in the app "just for testing". It ships. It always ships. Build the proxy first.
• A loop of single-day calls. Check for a range endpoint.
• Times look wrong on someone else's phone. Send the place and offset explicitly with every request.

Next

If a website would serve you better, the website guide is the shorter path — no app stores, no review. To connect MCP first, see the setup guide.