Mobile App

Gorilla Pulse Website & App

Gorilla Pulse is our own commercial software product: an iOS app plus a WordPress plugin system that gives WooCommerce store owners a 60-second morning check-in — yesterday’s numbers, today so far, alerts that need attention, and an AI they can ask about their store. We designed it, engineered it, licensed it, and shipped it through Apple’s App Store, end to end. This teardown is about what it takes to ship a real app product — because “we build apps” is a claim, and this is the receipt.

The brief we gave ourselves

Store owners check their numbers constantly — laptop, wp-admin, analytics tabs, repeat — and the ritual costs fifteen minutes to answer one question: “how are we doing?” The product had to answer that question in under a minute, on a phone, before coffee. And because it would be sold to non-technical store owners, setup had to take two minutes with zero API keys, zero configuration files, and zero developer involvement. Powerful for the owner, invisible in effort.

Architecture: an app, two plugins, and a deliberate split

The product is three coordinated pieces. The iOS app, built in React Native, is the owner’s window: the Pulse screen for the morning read, revenue and source trends, alerts, and the Ask interface. The store plugin installs on the customer’s WooCommerce site and serves secured, read-only data endpoints — the store’s numbers never leave the store’s control. And a server layer we run handles the product’s shared services: licensing verification and the AI processing behind Ask.

That split is the design insight of the whole product. Because the AI runs through our secured service, subscribers never create an API account, never paste a key, never see a token — the hardest part of “AI in your product” is handled entirely on our side of the fence. Setup for the customer is: install plugin, scan the QR code it shows, done. Paired in thirty seconds, with a revocable key the owner controls.

Why it matters to youIf you’re planning a product with AI in it, where the complexity lives is a business decision, not just a technical one. Push it onto customers and you’ve built a support burden; absorb it into your own service layer and you’ve built a feature. We chose the second, and it’s the difference between “install and scan” and a settings page nobody finishes.

The product: four screens and a rule

The app is deliberately small: a Pulse screen with daily summaries and a rolling seven-day history, revenue and traffic-source trends, alerts with push notifications so problems find the owner instead of waiting to be found, and Ask — plain-English questions answered from the store’s actual data. Ask ships with a rule we consider a feature: every number in every answer comes verbatim from the store’s own reports. The AI assembles the explanation but is never allowed to calculate or invent figures, and if the data doesn’t contain the answer, it says so. Enforced in the system, not promised in marketing.

There’s a fifth screen that says as much about the product as the four features: Support, built into the app. Questions go straight to the person who built it, and answers come back as push notifications. No portal, no ticket maze — for a product sold to busy owners, support is the product half the time.

The commercial machinery

A product isn’t shipped until someone can pay for it, so the commerce layer got real engineering too: subscription licensing integrated end to end — purchase on the web, license verified by the product, a stats-only trial so owners can see their own numbers before paying a dollar, and a usage cap on AI asks that keeps the economics honest at a flat $9/month (or $90/year). One tier, one price, cancel anytime: the same pricing philosophy as everything else we sell, applied to our own product first.

Shipping through the App Store

The part most “we’ll build you an app” pitches skip: Apple. Provisioning, builds, TestFlight beta cycles with real testers, review submissions, the rejection-and-resubmit rhythm, and the release pipeline for every update after — we’ve now run that gauntlet with our own product, including the unglamorous production lessons (build-toolchain pinning, cache-control discipline on live data endpoints, shipping around infrastructure outages) that only come from actually doing it. When we scope an app project for a client, the App Store isn’t a mystery line item; it’s a process we’ve completed.

The pattern worth copyingShip the smallest product that’s genuinely useful, then iterate through real releases — TestFlight builds, store updates, versioned plugins. Every piece of Gorilla Pulse (app, plugins, licensing) is on its umpteenth version, and that’s the point: products are shipped repeatedly, not once.

What it proves

We ship complete app products: iOS app, store plugin, server layer, licensing — one studio, end to end
AI can be a zero-config feature when the complexity lives in the product, not on the customer
Two-minute setup is an engineering outcome, not a marketing claim
Grounded AI — verbatim numbers only — is buildable and worth building
The App Store process is something we’ve completed, not something we’ll figure out on your dime

The stack, in one place

App: React Native iOS app — Pulse, trends, alerts with push, Ask AI, in-app support · Store side: WordPress/WooCommerce companion plugin, secured read-only endpoints, QR pairing with revocable keys · Server side: licensing verification + AI proxy (no customer API keys, ever) · Commerce: subscription licensing, stats-only trial, flat pricing · Distribution: Apple App Store via TestFlight beta cycles

See the product itself at gorillapulse.app. Like Gorilla Dirt and The Dirty Mule, it’s ours — built on our own time, sold under our own name, supported by the person who wrote it. If you’ve got an app idea attached to a real business, this is what shipping it looks like. We quote those flat.

Want Something Like This? Get a Quote Back to Work