DEV Community: Muhammad Najam Ul Hassan

What it actually costs to build an app, and how to compare two quotes

Muhammad Najam Ul Hassan — Sat, 31 Oct 2026 09:00:47 +0000

Nobody can price an app from one sentence. Here is what the price is actually made of, and how to get a quote you can compare against another one.

Short answer:

The number comes from screens, sign-in, payments, admin screens and integrations, not from the idea.
Small jobs start at $50. A full product is quoted as one fixed price after a free call.
Store accounts, hosting and any AI bill are running costs, separate from the build.
The cheapest quote usually leaves something out that you pay to add back later.

Why do two developers quote different numbers?

Because they are not quoting the same thing. One is quoting the app you described, and the other is quoting the app you will want in six months: the admin screen, the refunds, the offline mode, the second language.
There is no honest way to compare two quotes until you can see what each one includes. That is why I write the plan down before the price, so you can put my list next to anyone else's.

What actually moves the price?

These are the things I count when I quote. Each one is a real piece of work, and each one is also something you can choose to leave out of the first version.

How many screens there are, and how different they are from each other.
Whether people sign in, and whether there are different kinds of people with different views.
Whether money moves: cards, subscriptions, refunds, payouts, receipts.
How much admin sits behind it. Someone has to add the products, approve the jobs and fix the mistakes.
What it has to talk to: your shop platform, your accounts package, a spreadsheet, a supplier feed.
Content. Writing, photography and prices take somebody's time, usually yours.
The stores. Apple and Google both have accounts, rules and a submission process.

Does AI make an app cheaper?

It makes the typing faster, not the deciding cheaper. Screens and plumbing take less time. The plan, your data, payments, admin screens and store rules are the same work.
I wrote a separate guide on what an app built with AI costs, including the model bill that arrives after launch.

What costs do people forget?

The build is the number everyone asks about, and it is not the only one. These keep running after launch.

Cost	When you pay it	Who it goes to
Apple developer account	A yearly fee, before the app can go live	Apple
Google Play developer account	A one-off registration fee	Google
Domain name	Yearly	Your registrar
Hosting and database	Monthly, usually small at first	The host or platform
Payment processing	A percentage of each payment	The payment provider
AI model calls, if the product uses them	Monthly, based on volume	The model provider
Looking after it	Monthly, if you want an engineer on call	Me, on a support plan

How much does it cost to hire an app developer?

There is no single number, which is why quotes for the same idea range from a few hundred dollars to tens of thousands. The useful question is not the hourly rate, it is what the quote includes and who carries the risk when the estimate is wrong.
Hourly works when the work is genuinely unknown, like a rescue where nobody knows what is broken until the code is read. It punishes you when the scope is clear, because every change reopens the bill. A fixed price works when the plan is written down, because the number stays still unless the work changes.
Offshore teams are often cheaper per hour and cost more in the end when the time zone, the language and the handover add management you did not budget for. Local developers cost more per hour and can be faster to reach. Either way, what matters is a written plan and one person accountable for the result.
My fixed price includes the plan, the build, testing of the main flows, the store submission when there is an app, and the fix-it promise if what I deliver does not do what the plan says. Small jobs start at $50. The Apple and Google developer accounts and any hosting or AI bills are separate running costs you own.

How I quote

A free first call, then a written plan that says what I will build and what it will not do, then one fixed price. The price does not move unless the work does, and if what I deliver does not do what the plan says, I fix it at no extra cost.
Small jobs start at $50: a fix, a screen, a small automation. If the honest answer is that you do not need software at all, I will say that on the call instead of quoting you.

How to get a quote you can compare

Send the same short brief to everyone you ask. The more specific it is, the more the quotes mean.

Who uses it, and what each kind of user needs to do.
The screens you can already picture, even roughly.
Whether money moves, and who receives it.
Anything it has to connect to that already exists.
Your deadline, and what happens if it slips.
Who looks after it after launch.

Takeaways:

Price the screens, the sign-in, the money and the admin, not the idea.
Compare what is included before you compare numbers.
Budget for running costs from the day it goes live.
Get the plan in writing, so the price means something.

Q: Can you give me a price over email?
A: I can give you a small-job price, because those start at $50. For anything bigger I need to understand it first, and I would rather be accurate than fast. The first call is free and usually settles it.

Q: Do you charge by the hour?
A: No. You get one fixed price for the work in the plan. Hourly billing puts the risk of my mistakes on you, and that is the wrong way round.

Q: Is it cheaper to start with a website?
A: Often yes. A website can be found on Google and does not need two store accounts, so for one shop or one trade it is usually the sensible first step. I will tell you if that is the case for you.

Q: What if the price changes halfway through?
A: Only if the work changes. If you add something that was not in the plan, I will tell you what it costs before I build it, and you decide.

Q: Why do agencies quote more than you do?
A: An agency has more people to pay and more coordination, so the same work carries more overhead. That is not a comment on their quality, it is a different shape of business. With me you get one person who does the work and answers you directly.

Sources:

Apple Developer Program: https://developer.apple.com/programs/
Google Play Console registration: https://support.google.com/googleplay/android-developer/answer/6112435
Stripe pricing: https://stripe.com/pricing

This is a republished version of a guide from my own site: https://najam.dev/guides/what-an-app-costs/. If you want a straight answer about your own build, the contact details are on https://najam.dev.

n8n vs Make vs Zapier: pick by what you are actually automating

Muhammad Najam Ul Hassan — Sat, 31 Oct 2026 03:18:55 +0000

All three connect your tools without writing software. They differ in where they run, how they charge and how far they go before you hit a wall.

Short answer:

Zapier is the quickest to start and the most expensive at volume.
Make is the best visual builder for branching and reshaping data.
n8n can run on your own server, so there is no per-run fee and no limit on code steps.
If the automation is the product, none of the three is the right tool.

The short answer

For a small business that wants something running this week, Zapier or Make. For an automation that runs thousands of times a day, or that needs a real code step in the middle, n8n. The tool is rarely the reason an automation fails; an unclear rule is.

Pick Zapier if you want it working today, the flow is simple and the volume is low.
Pick Make if the flow branches and the data needs reshaping, and someone will look at it again.
Pick n8n if the volume is high, you need a real code step, or you would rather host it yourself.

How do they compare?

This is the comparison I run through with a client before choosing.

What matters	n8n	Make	Zapier
Where it runs	Their cloud, or your own server	Their cloud	Their cloud
How you pay	By workflow executions on their cloud, nothing extra if you host it	Per operation, including steps inside a scenario	Per task, per run
How many apps it connects	Fewer, plus anything with an API	A large library	The largest library
Code in the middle	A full code node, no limits	Limited scripting	A code step with limits
Branching and reshaping data	Good, and readable once you know it	The best of the three	Simple cases only
Who can maintain it	Someone technical	Someone patient	Almost anyone
Moving away later	Workflows are files you keep	Scenarios can be exported	Setups live inside Zapier

Where does each one hurt?

Every tool has the same complaint from the same kind of user. Knowing it in advance saves you the migration.

Zapier: the bill grows faster than the business, and multi-step logic gets awkward.
Make: the visual map becomes hard to read once a scenario has forty modules, and operations are easy to spend without noticing.
n8n: someone has to look after it, especially if you host it yourself, and non-technical colleagues will not edit it happily.

Where does AI fit in?

All three can call a model, and that is where most of my recent work has been. The useful pattern is not a chatbot: it is a narrow job, like sorting an enquiry, summarising a document or drafting a reply for a person to approve.
I keep the model step inside written limits: what it may decide, what it may never send without a human, and a log of what it was given and what it returned. That is what makes an AI step survivable in a real business.

When none of them is the right tool

An automation tool is for moving data between things that already exist. It is the wrong choice when the automation is the product, when the logic is genuinely complex, or when the volume makes a per-run fee silly.
At that point the honest option is a small piece of software with a database, which is also easier to test and cheaper to run. I would rather tell you that on the first call than build something you outgrow in three months.

Takeaways:

Start with the rule you want automated, not with the tool.
Count the runs before you pick, because that is what the bill follows.
Put AI steps behind written limits and a human approval.
If the automation is the product, build software instead.

Q: Which one do you use most?
A: All three, depending on the job. For a small business that wants to edit things itself, usually Make or Zapier. For volume or anything with a real code step, n8n.

Q: Can you take over an automation someone else built?
A: Yes. I read it, work out what it does and what breaks when it fails quietly, then tell you whether to tidy it or rebuild it.

Q: What if the app I use has no integration?
A: Then it probably has an API, and if it does not, there is usually another way in: an export, a webhook, or reading what the app already sends by email.

Q: Do I own the automation you build?
A: Yes. It is built in an account in your name, so you keep it whether or not I stay on. That is one reason I avoid setups you cannot leave.

Q: How much does an automation cost to run?
A: The tool's own fee plus any model calls. I work both out from published prices and your volume before I build, so the monthly number is not a surprise.

Sources:

n8n documentation: https://docs.n8n.io/
n8n pricing: https://n8n.io/pricing/
Make help centre: https://help.make.com/
Zapier pricing: https://zapier.com/pricing

This is a republished version of a guide from my own site: https://najam.dev/guides/n8n-vs-make-vs-zapier/. I build these automations for small teams and founders, so if you want a second opinion on which tool fits your case, the contact details are on https://najam.dev.

I take vibe-coded demos to production. Here is what actually breaks.

Muhammad Najam Ul Hassan — Sat, 31 Oct 2026 03:15:28 +0000

AI can take an idea to a working demo in days. Getting it ready for real payments, real data and the app stores is a different job, and it starts with reading the code.

Short answer:

A demo answers whether the idea works. Production answers whether it can hold real users, real money and real data.
AI tools are confident in the places where a mistake costs the most: permissions, payments, error handling and data access.
Cleanup is usually cheaper than a rebuild when the data model and the main flows are sound.
The first step is a code read: a written verdict on what is there, what is missing and which route costs less.

What is vibe coding cleanup?

Vibe coding is building software by describing what you want to an AI tool and accepting what it writes. It is genuinely fast at reaching a working screen, which is why so many ideas now get their first version this way.
Cleanup is the engineering pass between that demo and a product people can pay for. Someone who did not write the code reads all of it, tests the flows that carry money and data, and fixes the places where it would fail under real use.
It is not a rewrite by default. Most cleanup keeps the screens and the decisions that already work and repairs the parts a demo never had to prove.

What are the signs an AI-built app needs cleanup?

An AI-built app can look finished from the outside. These are the signs I look for when someone sends me one to inspect.

Nobody can explain what the database tables are for, or the same fact is stored in two of them.
Sign-in was added last, so some private screens can still be opened without it.
Keys or passwords sit in the browser code where any visitor can read them.
One failed payment or a dropped connection leaves a blank screen.
There are no tests, so nobody can change a screen without guessing what else breaks.
The same rule is written in three places and the three versions disagree.
Nobody has loaded it with more than a handful of records.
It has never been through store approval, or it was rejected and nobody knows why.

What does cleanup involve?

The work follows whatever the code read turns up, in the order that removes the most risk first. In most projects it lands in the same few areas.

Area	What gets checked	What usually changes
Data	Tables, relationships, duplicates and missing rules	A structure and migrations that match how the app actually works
Access	Sign-in on every private screen, and what each user can see	Permission checks on the server, not just hidden buttons
Secrets	Keys in the browser, in the repository and in the logs	Keys moved to the server and replaced
Payments	Failure, refund, retry and a double tap on Pay	One payment path with states that can be tested
Errors	What a user sees when a request fails	A message and a retry instead of a blank screen
Tests	Which flows are covered and what breaks on change	Tests on the flows that carry money and data
Speed	First load, long lists and a weak connection	Pagination, caching and lighter screens
Stores	Privacy, permissions and store rules	The settings and disclosures Apple and Google require

Cleanup or rebuild: which is cheaper?

A rebuild is not automatically cleaner. Starting again throws away the screens that work and every decision already tested with users, and it can repeat the same mistakes if the plan does not change.
Rebuild when the data model is wrong at the root, when the tool cannot give you usable code, or when every screen depends on every other one and no part has ever been tested. Clean up when the main flows work with real data and the problems are concentrated in a few areas.
A code read decides it. I read the code, test the main flows and write a verdict that prices both routes, whether or not you hire me for the work.

What the read finds	Cleanup	Rebuild
Main flows work with real data	Usually the cheaper route	Rarely worth starting over
The tool cannot export usable code	Not possible	Rebuild in code you own
The same fact is stored in three tables	Possible, but expensive	Often cheaper over time
The problems are access, keys and payment states	This is cleanup work	A rebuild repeats them unless the plan changes

What does vibe coding cleanup cost?

Cleanup is quoted as one fixed price after a code read, because the number follows what is actually in the repository rather than what the demo shows. Small jobs start at $50 for a single fix or a look at one screen.
A cleanup that touches payments, permissions and tests is a build-sized job. It is still usually less than a rebuild, and you keep the parts that already work. The code read is the cheapest way to find out which route you are on, so ask for it before agreeing to any number.

Can you work with apps built in Lovable, Bolt, Base44 or Replit?

Yes. What the tool exported matters more than which tool it was. If it gives you a code repository, the cleanup happens in that code and nothing has to be thrown away first.
If it only gives you a hosted app with no usable export, the first job is getting the data out and deciding whether the screens are worth rebuilding. Either way, you end up owning the code, the data and the accounts.

What should I prepare before a code read?

The read goes faster when I can see the app as a user sees it and reach the code in the same session.

A link to the live app, and a test login for each kind of user.
Access to the code repository, or an export from the tool that built it.
A short list of what worries you most, even if it is only a feeling.
The flow that makes money, described in a sentence, so I test that one first.

Takeaways:

A working demo is the start of the engineering, not the end of it.
AI writes plausible code. Permissions, payments and failure states still need a person to check them.
Cleanup beats a rebuild when the data model and the main flows are sound.
Get a written code read before you agree to a cleanup price or a rebuild.

Q: What is vibe coding cleanup?
A: It is the engineering work that turns an AI-built demo into something safe to charge money for: reading the code, fixing access and payment failures, adding tests and preparing the app for the stores. Most of the time it keeps the screens that already work.

Q: How do I know if my AI-built app is safe to launch?
A: Try it the way a stranger would. Sign out and open a private screen, pay with a test card and make the payment fail, drop the connection halfway through a form. If any of those breaks the app or shows data it should not, it is not ready.

Q: Can you clean up an app built with Lovable, Bolt, Base44 or Replit?
A: Yes. If the tool exported a code repository, the work happens in that code. If it only gave you a hosted app, the first job is getting the data out and deciding whether the screens are worth rebuilding.

Q: Will cleanup break the features that already work?
A: It should not, and that is why tests come early. Each feature that stays gets a test before it is touched, so a change that breaks something is caught before your users see it.

Q: How long does a cleanup take?
A: Days for a small app with one broken area, weeks when access, payments and tests all need work. The code read gives you a date and a fixed price before the work starts.

Q: Should I rebuild instead of cleaning up?
A: Only when the data model is wrong at the root, the tool cannot export usable code, or nothing has ever been tested. A rebuild costs more and takes longer, so it should be the answer the code gives, not the safe default.

Q: Will I lose users or data during a cleanup?
A: No. The database stays in place, and any change to its structure is planned and run against a copy first. Your users keep using the app while the work happens.

Sources:

Submitting an app to the App Store: https://developer.apple.com/app-store/submitting/
Google Play Developer Policy: https://play.google.com/about/developer-content-policy/
OWASP Top 10: https://owasp.org/www-project-top-ten/
Stripe security documentation: https://docs.stripe.com/security

FAQ

This is a republished version of a guide I wrote for my own site, and the original lives at https://najam.dev/guides/vibe-coding-cleanup/. If you have an AI-built app and are not sure whether it can take payments or pass store review, the fastest way to find out is a code read. My contact details are on https://najam.dev.