Straight answers on cost, time and scope

Not answerable before scoping, and a supplier who gives you a figure on a first call is either guessing or pricing a different job. What moves the number, roughly in order of how often it is underestimated: how many distinct kinds of user there are, because each brings its own permissions and screens; how many other systems it has to talk to, because every integration is a separate piece of work with someone else's schedule attached; whether years of existing data have to be migrated, where the cleaning costs more than the code; whether it must keep working with no signal; and whether it goes through an app-store review. Scoping produces a range with the low and high end explained, which is enough to compare us with anyone else. The number comes after.

The floor is set by how much has to be decided and how many systems have to be connected — not by how fast anyone writes code. Three things stretch a timeline, and none of them is coding speed: decisions waiting on someone at your end, access to a system nobody can actually grant, and a definition of “done” that was never agreed so the work keeps growing. Scoping exists to name all three before they become delays. A timeline offered before scoping is a guess, and the honest version of it is a range.

A real trade rather than a preference. Fixed price needs a frozen scope, and the supplier prices the risk of being wrong into the figure — so you pay a premium for certainty and lose the ability to change your mind cheaply. Time and materials is cheaper when the scope is genuinely unclear, and it requires enough trust, plus a regular review, that you can see where the money is going. The failure mode to avoid is a fixed price on a vague scope: it guarantees an argument, because every clarification becomes a negotiation about whether it was included.

Less than you would think, and none of it technical. Describe the task as it happens today: who does it, how often, what they start with, what they have to produce, and what goes wrong now. Screenshots of the spreadsheet people actually use are worth more than a requirements document. Name any system it has to work with, and say whether anyone has credentials for it. If something already exists, say who built it and whether you have access to the code. You do not need a budget figure, a technology preference or a specification — arriving with those often narrows the job before anyone has checked the narrowing was right.

Compare five things, none of which is the price. First, the scope document: does it describe your process in language you can check, or does it describe a generic project? Second, ownership: are the repository, hosting, domain and store accounts in your name — if not, you cannot leave. Third, what happens after launch, and whether that was quoted or assumed. Fourth, whether they told you anything you did not want to hear; a supplier who agreed with everything has not read your problem. Fifth, what they say they would not build, and why.

The work of planning, designing, building, testing, deploying and then maintaining software — the last of which is usually the longest phase and the one left out of the budget. The kinds that matter to most organisations are web applications, reached through a browser; mobile applications, installed on a phone or tablet; and integrations, which connect systems that already exist rather than building anything new. Which of those your problem needs is a question the first conversation answers, and it is worth arriving without having decided.

Worth settling in the scope rather than at the end, and worth asking any supplier before you sign. The questions that matter: in whose name are the repository, the hosting account, the domain and any app-store account held; who can grant access to each of them; and what you receive on the last day of the arrangement — the code, the credentials, the deployment instructions and whatever documentation exists. An arrangement where the supplier holds the accounts in their own name is one you cannot leave, and that is usually discovered at the worst possible moment rather than at the start.