Service
Building the thing your customers or your staff actually open on a phone, with the scope, the ownership and the cost of keeping it running settled before any of it is written.
Almost everybody arrives with the idea and not yet with the decisions underneath it.
Most people who ask about an app have a clear picture of what it should do and no settled answer to the questions that will decide what it costs. Who is opening it, and how often. Whether they log in. What happens to their information. Which parts have to work when the signal drops. Whether it needs to reach anything you already run, like a booking system or a customer database.
That is normal. It does mean the first stretch of work is deciding those things. A build started before them gets rebuilt after them. The single most expensive pattern in this field is a project where the scope was agreed as a paragraph and discovered as a series of surprises.
So, this page is mostly about what gets settled before the writing starts, what an app costs to keep alive after launch, and what you should have in hand before you talk to anybody, including us.
Sometimes yes, clearly. It is worth ten minutes to know which case you are in.
A modern website already does a great deal on a phone, including taking payments, holding an account, and working offline to a degree. So, the useful question is not whether an app is impressive but whether it earns the extra work of two app stores, two platforms, review queues and update cycles.
It usually earns that under five conditions: people use it repeatedly, they sign in and it remembers them, it needs the phone itself for a camera or a scanner or background location, notifications are part of the job and not marketing, or it has to keep working with no connection. A field crew logging jobs on a site with no signal needs an app. A restaurant menu does not.
Where the answer comes back as a website, that gets said, and it is not a smaller project or a lesser one. Where it comes back as an app, the reasons are written down, because those same reasons are what the scope is later judged against.
No fixed price is possible before the scope is written, but the things that move it are knowable now.
Four stages, and the first one produces a document on purpose.
Who uses it, what they are trying to finish, what the app must do for that to count as done, and what is explicitly out of scope for the first release. This produces a prioritised list and a definition of the smallest useful version, agreed in writing. It is the stage most often skipped and the one that decides whether the rest of the project is comparable between providers or a matter of trust. Usually two to four weeks.
Screens that can be tapped through on a real phone, with no working code underneath. This is where a misunderstanding costs an afternoon. Found later it costs a month. People discover what they meant by looking at it, which is not a failure of the brief but the ordinary way a product gets understood, and it is far cheaper to find out here.
Version control, code review, automated tests where they earn their keep, and staged releases so something works and is checked before the next part is added. Security is handled while the thing is being built, following the published secure-development guidance and not somebody's private opinion about what is safe. You see working versions throughout instead of a demonstration at the end.
Store submission with the privacy declarations completed accurately, monitoring so we see a crash before a customer reports one, backups, and a written handover of every account and key. The maintenance arrangement is agreed before launch. An app with no plan for its second year becomes a liability.
Ownership is settled at the start.
The prioritised list, the smallest useful release, and what was deliberately left out of it, with the reasoning.
Handed over with its history whenever you ask for it, so another developer can pick it up.
Developer accounts, store listings, signing keys and any service credentials, all registered to you.
How it is built, what it depends on, how it is released, and what has to be renewed and when.
Approval is not automatic, and the common reasons are dull.
Apple reviews every submission and Google holds the developer responsible for the accuracy of what the listing declares about data. Rejection is a normal part of the process. It is also a scheduling risk, which is why a launch date should never be promised as a single day to a customer or to your own staff.
The frequent causes are ordinary. An incomplete submission where the reviewer cannot actually reach the thing being reviewed, because it needs a login and no test account was supplied. Privacy information that does not match what the app really collects. Links that go nowhere. A first release thin enough that a reviewer reads it as a repackaged website.
All of those are avoidable by preparing the submission properly, which is why it sits in the plan as a task with time attached. Where a rejection does happen, you get told the reason and we resubmit a corrected build.
An app is not finished when it ships, and budgeting as though it is causes most of the trouble later.
Phones update twice a year and things break that nobody touched. Libraries the app depends on get security fixes that have to be taken. Store requirements change and a listing that was compliant becomes non-compliant without anybody doing anything. Certificates and developer accounts expire on their own schedule, and an expired signing certificate can pull a live app out of the store.
None of that is unusual and all of it is predictable, so it belongs in the plan from the start. That means an agreed arrangement for updates, somebody named as responsible for watching the crash reports, and a renewal calendar handed over with everything else.
The alternative is very common: an app that works beautifully for a year, stops being updated, and ends up unsafe to change because the developer moved on and nothing was written down. Avoiding that is mostly a matter of deciding it in advance.
Each of these makes every quote you receive more comparable.
Write one sentence describing who opens the app and what they are trying to finish when they do. Not the feature list, the job. Almost every scope disagreement traces back to this sentence never having been written.
List what has to work offline, if anything, and be precise about whether that means reading information or changing it. They are very different requests and they are priced very differently.
Name the systems it would need to talk to, and find out now who controls access to each. The answer is sometimes a former supplier or a member of staff who has left, and discovering that early is much better than discovering it mid-build.
Decide who inside your business will make decisions and how quickly. An app project stalls on unanswered questions more often than on hard engineering, and a named person with the authority to choose is worth more to the timeline than any technology decision.
Delivered locally across these areas, and remotely beyond them.
Often, and it is the first thing we work out together. Apps earn their extra cost with repeat use, accounts, notifications that are part of the job, device features like the camera or background location, and real offline working. Where none of those apply, a website usually does the same job for less.
No figure is possible before the scope is written, and a fixed price quoted earlier is a guess. What can be said in advance is what moves it: whether people log in, how many other systems it must talk to, what has to work offline, and whether it is for the public or for your own staff.
Yes, and one codebase can serve both. That does not remove the need to test on both, because the platforms behave differently, their accessibility features differ, and each store has its own requirements.
It means the smallest release that is useful to somebody. It does not mean a rough one. The point is to put a finished small thing in real hands and learn from it. The alternative is shipping something large built entirely on assumptions. The quality bar is the same; the scope is narrower.
You do. The developer accounts, the store listings and the signing keys are in your name from the first day, because those are the ones that are painful to move later. The source code is handed over with its history on request, so another developer can continue from it.
It happens, and there is time in the plan for it. The common causes are an incomplete submission, missing test credentials, privacy information that does not match the app, and broken links. Those are prepared for in advance, and a rejection means a corrected resubmission with the reason shared with you.
Send the one sentence describing who opens it and what they are trying to finish, plus anything it would have to connect to. That is enough for a first answer about whether this is an app or a website, and about which parts of it will drive the cost.
