Almost every message that reaches me through my contact form starts the same way: an idea for an app and the question of how much it will cost. It's the first thing I'd want to know too. The trouble is that, without more context, any figure I gave you would be plucked out of thin air.
So instead of a price, I'll walk you through what actually drives the budget for a custom app, with examples from things I've built. Once you understand these pieces, you'll be able to ask for quotes you can compare and spot when someone is offering you something very different from what you need.
Scope: what it has to do on day one
This is by far the biggest factor. An app with a login and three screens is a different job from one with profiles, user-generated content, chat and notifications. Each new feature doesn't just add a screen: it adds server logic, edge cases and testing.
In Echoes, the app I'm building for club culture, the heart of it is the Memory Vault: a diary of your nights with photos, line-up and voice notes. Around it sit squads with real-time chat, direct messages, Echo Pulse (you record ten seconds of the room and the server works out the BPM) and an AI-written summary of your nights. Each of those is a block of work with its own cost.
The AI summary in the Echoes Memory Vault: one more integration that counts towards scope.Integrations belong in the same bucket. Every external service the app talks to is another piece: payments, maps, push notifications, third-party sign-in, AI. You don't build them from scratch, but they have to be wired up, made to fail gracefully and tested properly. RARG runs its subscriptions on Stripe, and so do the shop payments at Centro Vuela. Those are websites, but integrating payments is much the same job in an app.
That's why I always suggest separating the essentials from the nice-to-haves. A first version that solves one problem well ships sooner, costs less and shows you what users actually ask for. Everything else can wait for phase two.
Platforms: iOS, Android and what sits behind them
A few years ago, having your app on both iPhone and Android meant building it almost twice. These days I work with Expo and React Native: one codebase for both platforms. That's how Echoes is built, and I can also ship fixes as OTA updates without going through a new store review every time.
What many quotes leave out is that an app rarely stands on its own. It needs a backend: an API that stores the data, manages users and does the heavy lifting. For Echoes that's Laravel with MySQL, and it's where the BPM of each Pulse is calculated with ffmpeg and aubio. If someone quotes you for "the app" alone, ask who builds and who maintains the server.
There's also admin that isn't programming but still takes time: the Apple and Google developer accounts, which have their own fees and are best kept in your name, the store listings, screenshots, a privacy policy and each store's review before you go live.
Design: template or screen by screen
Design can range from adapting a standard component system to designing every screen with its own identity, animations and micro-interactions. Both are valid choices. They cost different amounts.
The screen for creating an Echo: designed before a single line of code was written.I designed Echoes screen by screen before coding it, with animations built in Reanimated and Skia. It's more work up front, but it saves a lot later: by the time I reach the code I know exactly what to build, and we don't end up redoing screens halfway through.
If you already have designs from another studio, that shows in the quote too, as long as they're complete. Check they cover empty states, errors and loading screens, because that's exactly where people tend to improvise.
The hidden parts: admin panel and maintenance
There's one piece hardly anyone asks for and almost everyone needs: the admin panel. Someone will have to add content, review users or deal with issues. In my projects I build it with Filament, connected to the same database as the app, so you don't need me to change a line of text. Leave it out of the quote and you'll end up paying for it in support hours.
And a published app isn't finished. Apple and Google release new versions of their operating systems every year, libraries get updated, bugs appear that only real users uncover, and the server needs backups and monitoring. You need to plan for maintenance even if the app doesn't grow.
When you compare quotes, ask what that maintenance covers: dependency updates, compatibility with new iOS and Android versions, server hosting, backups and how quickly someone responds if something breaks. Ask too who owns the code and whose name the accounts are in.
How to ask for a quote that's actually useful
A good quote starts with a good brief. You don't need a fifty-page document. This is enough for me to give you a serious first answer:
The problem it solves and who for. One clear sentence beats a list of features.
The essentials for the first version, kept apart from what can wait.
Platforms: iOS, Android, web or all of them.
What you already have: designs, a website, a database or a system it needs to connect to.
Who will run it once it's live.
The date: if there's an event or launch that can't move, say so from the start.
And if you have a rough budget in mind, share it. Not so it gets spent in full, but so I can suggest the version that best fits what you can invest, rather than designing something ideal that then has to be hacked back.
That's why my contact form asks what you need, a rough budget and your timeline. With that, I'll reply within 24 working hours with a first idea of how I'd approach it and what it might cost.
If you've got an idea going round in your head, don't wait until it's perfect to tell me about it. We'll pin it down together. Tell me about your project.
