I build apps that end up on your customers' phones and get opened again: bookings, orders, notifications and payments in their pocket. I design them, build them and publish them myself on both stores, and I stay when the operating system moves. But first I will tell you honestly whether you need one.
First things first
An app costs money and then lives for years. Before quoting one it is worth settling whether it is the right tool for your problem, because often it is not.
Nine times out of ten there is another sentence underneath it: I want customers to book without ringing me, I want to stop writing orders on a scrap of paper. Sometimes the answer really is an app; sometimes it is a booking page built properly, which costs less and arrives sooner.
You need one when the same people come back and repeat the same action: booking a sunbed every Saturday, ordering without getting up from it. There the icon on the phone removes friction every time, and a notification arrives without buying attention. Beach clubs, gyms and venues are where an app pays for itself.
If your problem is reaching people who have never heard of you, an app will not fix it: on the store you are searched for by name, by people who already know it. Start with a website that gets you found and add the app afterwards.
What it covers
An app is not finished when the code works: it is finished when it can be downloaded. And from there the long part begins.
1
Before a line gets written we put in writing what the app does and which two or three actions a person will genuinely perform. Out of that comes the proposal: what goes into the first version, what waits for the second.
2
The app is built once and runs on iPhone and Android with the same screens and the same logic. You try it as it grows: I send you builds you can install on your own phone, so corrections land while they are cheap.
3
The part that scares everyone, and the part I handle: Apple and Google developer accounts opened in your name, both store listings, icon, screenshots in every required size, the privacy and data declarations, and the back and forth with the reviewers until the app is live.
4
iOS and Android change every year and the stores set deadlines to keep up: an app left alone breaks on its own. I keep it in line, fix what real use turns up, and republish on both stores.
Analysis→ Build→ On your own phone→ Store review→ Updates
Under the hood
Three ways of building the same thing. What changes is the cost, the time and how much the app can ask of the phone, explained the way I explain it to people who do not write code.
Written in each phone's own language: one version for iPhone, one for Android, two builds, two maintenance jobs. It earns its keep when the phone has to be squeezed: heavy graphics, sensors always on. For booking a sunbed it is like buying a lorry to do the weekly shop.
Two codebases · two maintenance jobs
A single codebase that becomes a real app on both stores: same icon, same notifications, the same presence on App Store and Google Play. It costs less than two native apps, updates in one go, and for bookings, orders and payments it does the same job.
Angular · Ionic · Capacitor · React Native
A website built to behave like an app: one tap adds it to the home screen, it opens full screen with no browser bar, and it copes when the signal drops. It never touches the stores: no review, no waiting, what I fix this morning is on your customers' phones today. It suits you when the stores buy you nothing.
No store · instant updates
A push notification is the only channel that reaches a phone without buying attention, which is why it should be used sparingly: confirmations, reminders, the season opening, never leaflets. Payments go through Stripe and land in your own account: the same machinery as the booking platforms I build.
Push notifications · Stripe
Work
You book your spot and order at the bar from your phone, on a Tuscan beach that welcomes dogs. On App Store and Google Play since 2020.
A beach club on the Costa Viola: sunbeds, tables and orders from the lounger. On both stores and, uniquely among my projects, as a PWA too.
Direct messages from fans to the people they follow, from the phone or the browser. I coordinated its development at RJC Soft, all the way to the stores.
Questions
There is no price list, and anyone who hands you one is guessing. Three things move the number: how many actions the app has to handle, what it has to talk to (your back office, payments, a calendar) and how many people need to administer it. Plus two lines that only apps have: keeping both store accounts compliant, and going back into the code every time Apple or Google raise the bar. After the first call you get a written proposal.
No. If what you need is bookings, orders and payments, a PWA does the same job: it installs from a link, it skips the review and it updates the moment I say so. The stores are worth it when being on App Store and Google Play is part of how you present yourself, or when you need phone features the browser will not hand over. A PWA can move to the stores later, same project.
The length of the review. Apple and Google check the final build before it goes live: they may ask for a change to the listing, an explanation of what data you collect, or a fix inside the app. I answer and resubmit until it passes. Which is why a submission never goes in the day before a seasonal opening.
It goes wrong slowly, then all at once. iOS and Android ship a new version every year and the stores set deadlines to keep up: an app left alone first breaks on some phones, then stops accepting updates, and eventually drops off the store. That is why maintenance sits in the proposal next to the development, not as an extra for later.
06 · Contact
Tell me what happens at your counter or on your phone today, and what you would like to happen inside an app. You get an honest answer within 24 hours, including the one where the app can wait.