What 'an app' actually contains
The word compresses a dozen separate pieces of work, and most of them are invisible until they are missing.
Product strategy. UX logic. Onboarding flows. Admin tooling so somebody can actually run the thing. API decisions. App Store setup. Testing. Analytics. Edge-case handling. Post-launch improvement. None of these appear in a description of an app, and all of them appear in the work.
When a founder says the quote seems high, they are usually comparing it against the screens they can picture. They are not comparing it against the list above, because they have never had reason to know that list exists.
What drives a quote up
It is almost never the number of screens. It is the number of decisions the screens are hiding.
The things that genuinely move a price: how many kinds of user there are, whether the product logic is clear or still being worked out, custom workflows, API complexity, payments, admin and dashboard requirements, deployment and store submission, edge cases, and the testing burden that comes with all of it.
The thing founders reliably assume is driving the price, and largely is not: screen count. Twenty simple screens with one user role and no payments is a smaller build than six screens with three roles, a permissions model, and a Stripe integration. The interface is not where the cost lives.
Freelancer or studio
The honest version of this trade-off is about who does the thinking, not who writes the code.
Founders choose a freelancer for price, and often that is the right call. If the product is fully specified, the flows are decided, and you know exactly what you want built, you are buying implementation and you should pay implementation prices.
The reason founders come to a studio instead is usually that the product is not specified yet, and they have realised they need someone to think it through with them rather than take dictation. The mistake is paying implementation prices for a project that still needs the thinking done, and then discovering the thinking has been done badly, by default, in a hurry, by someone who was never asked to do it.
Two questions that predict the outcome
You can usually tell how an engagement will go from the first conversation.
The question that predicts trouble is some version of: can you just build all the features first, and we will figure out the details later? It sounds efficient. What it means in practice is that the decisions will still be made, but they will be made silently, by a developer guessing, without you in the room.
The question that predicts a good outcome is the opposite: what should we cut from v1 so we can launch the strongest first version properly? A founder who asks that has already understood the thing that matters most. The first version is not a smaller version of the final product. It is a different object with a different job.
What should never get cut
Budget pressure is normal. Some things survive it and some things must.
Cut secondary flows, advanced admin, nice-to-have automations, complex dashboards, and any polish that does not touch the core journey. All of that can wait, and most of it should.
Do not cut the core user journey, the product logic, onboarding clarity, authentication and account access, basic QA, deployment and release setup, or the handover of ownership and access. Everything on that list is the difference between a product you have and a product you merely paid for.
Where Wall & Fifth sits
Most of the value in a first build arrives before anyone writes code.
The engagements that go well are the ones where the scope conversation happened properly. What the first version is for, what it deliberately excludes, and what has to be true on the day it launches.
For a defined first version, that is New Builds. Where the product direction needs to stay open while the software takes shape, it is usually Embedded Partner.
This is written for founders who
This is written for founders who
- Can describe the outcome clearly but not the flows, logic, or scope beneath it
- Are comparing quotes and cannot tell why the numbers differ so much
- Have been told a build will take six weeks and have no way to check
- Are about to sign something and are not sure what they have agreed to
FAQ
Questions people usually have before the next step feels obvious.
How do I judge a developer if I cannot evaluate their code?
Judge the questions they ask you. A developer who asks about user roles, edge cases, what happens after launch, and what should be excluded from the first version is thinking about your product. One who only asks for a feature list is thinking about your money.
Why do quotes for the same brief vary so much?
Because the brief is rarely the same thing to two people. One quote may assume you have decided the product logic; another may include working it out with you. One may exclude admin tooling, testing, and store submission; another may include them. The number differs because the scope differs, and the scope differs because nobody wrote down the exclusions.
Who should own the code?
You should, and it should be written into the contract rather than assumed. The same applies to accounts, API keys, deployment access, store credentials, and documentation. Ask before you sign, not after. This is the single most common thing founders discover too late.
What should be in the first version?
The core user journey, the product logic, clear onboarding, working authentication, basic QA, a real deployment path, and a clean handover of access. Almost everything else can be argued about later. Very little of it needs to exist on day one.
Is a freelancer cheaper than a studio?
For implementation of a fully specified product, usually yes, and that can be the correct choice. The cost comparison changes when the product is not specified, because someone has to make those decisions and the price of making them badly is paid later, during a rebuild.
Related pages
Useful next step
If the outcome is clear but the scope is not, that is the conversation worth having first.
The first version is cheaper, faster, and better when the exclusions are decided deliberately rather than discovered halfway through.