Engineering
App Development: one app for the web, iPhone and Android
App Development is one app that runs on the web, iPhone and Android from a single codebase, with logins, Stripe payments, emails and error reports built in. From £7,500, or £1,999 to put a web app you already have in both stores. First version in 8 weeks.
Why not build separate apps for iPhone and Android?
Most owners who need an app get told they need three: a website, an iPhone app and an Android app. That is three builds to pay for, and every bug gets found and fixed three times.
The other route is a no-code builder, which is fine until you need payments that work your way, or want to leave and find your app does not come with you.
There is a middle path that small teams use quietly: build one web app properly, then wrap it for both stores. That is how I built GigXchange, and it is what you get.
How does this compare with a no-code builder or native apps?
A no-code builder keeps your app inside its platform, and separate native apps mean two or three codebases. App Development is one codebase for the web and both stores, with Stripe built in and store releases automated.
| A no-code app builder | Separate native apps | App Development | |
|---|---|---|---|
| Codebases | One, inside their platform | Two or three | One, for the web and both stores |
| Payments | Their add-ons | Built once per app | Stripe, built in |
| Store release | Depends on the plan | By hand, per app | Automated for both stores |
| When it breaks | Hard to see why | Found per app | Reported the moment it happens |
| Customer data | On their terms | Often copied twice | One layer, locked per user |
What do you get in the first version of an app?
App Development gives you one codebase, email and Apple sign-in, Stripe card payments and refunds, emails from your own domain, error reports, one data layer that keeps each person to their own data, and automated store builds.
- 01
One codebase
One app that runs in a browser and inside a native shell for iPhone and Android. Fix it once, fixed everywhere.
- 02
Logins
Email sign-in and Sign in with Apple, with password resets and sessions handled properly.
- 03
Payments
Card payments, refunds and payouts through Stripe, with the rules that stop money going missing.
- 04
Emails
Receipts, confirmations and reminders sent from your own domain.
- 05
Error reports
When something breaks for a customer, you get a report with what happened - not a one-star review.
- 06
One data layer
Every read and write goes through one place, so each person only ever sees their own data.
- 07
Store release
Builds for the App Store and Google Play made in the cloud and submitted from one command.
What does a small-business app need on every device?
An App Development build covers the parts most small-business apps need - sign-in, a card payment, a receipt email, push notifications and an error report - built once and shipped to the web, the App Store and Google Play.
One build, three places
- Sign in with email
- Sign in with Apple
- Take a card payment
- Send a receipt email
- Push notification
- Error report to the founder
- Web: yourapp.co.uk
- iPhone: App Store
- Android: Google Play
- 100screens in the GigXchange app, one codebase
- 9Stripe payment functions behind it
- 2app stores, released by one command
Source GigXchange's own figures, as of 25 October 2026
How long does it take to build an app?
App Development takes eight weeks to a first version: week one to plan, weeks two and three to design every screen, weeks four to seven to build, and week eight to ship. Apple and Google then decide how long review takes.
- 01
Week 1
Plan
We agree what version one does and, just as important, what it does not.
- 02
Weeks 2-3
Design
Every screen drawn at phone and desktop size. You click through it before a line is built.
- 03
Weeks 4-7
Build
Logins, payments, emails and your core screens built, with a test version on your phone each week.
- 04
Week 8
Ship
Live on the web, and submitted to the App Store and Google Play for review.
Is a custom app right for your business?
App Development suits a business whose customers need to log in, book or pay, and that can say what version one must do in a page. It is the wrong fit for a 3D game or a brochure site.
A good fit if
- Customers need to log in, book or pay
- You can say what version one must do in a page
- You can wait for Apple and Google to review it after week 8
Not for you if
- You need a 3D game or heavy graphics
- You only need a brochure site - that is Web Development
- You want every feature in version one
Questions
07Asked and answered
A first version starts at £7,500, which covers logins, payments, emails, error reports and your core screens on the web, iPhone and Android. If you already have a working web app and only need it in the stores, the store wrapper on its own is £1,999. Anything beyond a first version is quoted in writing before work starts. App store fees are paid by you directly to Apple and Google.
The app is built once as a web app, then placed inside a native shell for each phone using a tool called Capacitor. The shell gives it the things a website cannot do on its own: push notifications, sharing, Sign in with Apple, a proper home-screen icon. Customers download it from the store like any other app. For most business apps - bookings, accounts, payments, messages - they cannot tell the difference.
A first version is the smallest app that does the one job your customers need, done properly. Usually that is signing in, doing the main thing - booking, ordering, managing an account - paying, and getting a confirmation. We write it down in week one as a short list, and anything not on it waits for version two. That list is what keeps the price fixed and the date honest.
The app is finished and submitted in week 8; after that, Apple and Google decide how long review takes. It is often a day or two, sometimes longer if they have questions. I prepare the submission against Apple's App Review Guidelines so it is not rejected for avoidable reasons. The web version goes live the day it is finished, so customers are not waiting on review.
Payments run through Stripe, so card details never touch your app or your database. Stripe handles the card, the bank and the fraud checks; your app records what was paid and for what. On GigXchange that is 9 separate payment functions - taking money, refunds, tips, releasing funds - each with checks that stop a payment being counted twice or lost.
Yes - each customer can only see their own data, and that rule lives in the database itself, not just in the screens. It is called row-level security: every table checks who is asking before it hands anything back. It is the same work as a Database Security Audit, done from day one. If you hold personal data, the GDPR Compliance Kit covers the paperwork side.
Web changes go live straight away; store changes need a new release and a fresh review. Because an installed app is a copy you cannot reach, I build so older versions keep working when the server side changes - customers who never update are not left with a broken app. For frequent changes, a Deployment Pipeline checks every update before it ships.
Yes. The code, the store accounts, the Stripe account and the database are all in your name from day one. Apple and Google require the developer account to belong to the business anyway, and I set it up that way. If you take the app to another developer, they get one tidy codebase, not three, with notes on how it is put together. Nothing about the app depends on me staying involved.