Short answer: a startup on a strict budget should buy a smaller first version, not a cheaper team. One senior team, one user journey, a real backend, both stores, roughly €9,500 fixed. Cheap hourly teams cost less per hour and more per shipped feature.
Cheap and affordable are different words
A €150-a-day developer is cheap. A €450-a-day senior who ships the same feature in a third of the time is affordable. The distinction only becomes visible when you count delivered scope rather than invoiced hours, which is exactly the number nobody tracks during the first two months.
Where cheap actually costs more, in the order we see it happen:
- Re-specification. Junior teams build what the brief literally said. Senior teams ask the question the brief should have answered. The first path gets you a correct implementation of the wrong thing.
- Rework after real users. A data model that cannot express the second pricing tier is not a bug; it is three weeks.
- Handover. The cheapest teams document the least. The bill arrives when you change supplier.
What to cut from version one
Almost everything. The discipline is to keep exactly the loop that proves someone will pay, and to defer every branch off it.
Cut: second and third user roles. Admin panels — use the database console for three months. Settings screens. Notification preferences. Onboarding carousels. Profile editing. Dark mode. Anything that appears in the brief with the phrase "while we're in there".
Keep: one user type, one journey end to end, one payment path if money is part of the hypothesis, and the ability to see what people actually did.
This is not a lower-quality app. It is a smaller one, built properly, which is a completely different thing from a large one built badly.
Every feature you defer is a hypothesis you get to test with evidence instead of funding with faith.
What never gets cut
Four things cost a day or two each and repay themselves the first week you are live:
Crash reporting. Without it your bug tracker is the App Store review page, which has a two-day latency and a public audience.
Analytics on the core loop. Three events — started, completed, abandoned — tell you more than any amount of user research about a product that is already live.
CI and automated builds. Manual builds from a laptop mean releases depend on one person being awake, and they are how signing keys get lost.
Forced-upgrade handling. A single remote flag that can tell old clients to update. Without it, your first breaking API change means supporting every version ever installed, forever.
Why fixed price suits a first version
Hourly billing transfers all estimation risk to whoever has the least information about the work — you. It also removes any structural reason for the supplier to be fast.
A fixed price forces the uncomfortable conversation to happen before money moves: what exactly are the acceptance criteria, what is explicitly out, and what happens when you change your mind. That conversation is unpleasant for a week and saves the project.
Our shape, published rather than negotiated:
| Price | What it is | |
|---|---|---|
| Scoping week | Paid, credited against the build | Intent turned into acceptance criteria |
| First version | €9,500 fixed | Live in both stores, real users, real backend |
| Changes | €450 a senior day | A number, not an argument |
| Continuing team | €7,000 a month | Senior, dedicated, no bench |
The uncomfortable advice
If the total budget is under about €6,000, do not commission a custom app yet. Validate with a mobile web build, a no-code assembly, or a concierge process run by hand. Spending your whole runway on v1 of a native product is the most common way a good idea dies with a working app attached to it.
If the budget is there, buy the bounded slice, ship it, and decide the next three months with data. Our pricing is public and the contact form reaches an engineer.
Frequently asked
What is the realistic minimum to get a startup app into the stores?
Around €9,500 for a bounded first version built by senior engineers: one user journey, a real backend, both stores, crash reporting and CI. Below roughly €6,000 you are buying a prototype, which is fine as long as everyone says so out loud.
What should a startup cut from version one?
Second user roles, admin panels, settings screens, notification preferences, onboarding tours, and anything described as 'while we're in there'. Keep exactly the loop that proves someone will pay.
What should never be cut?
Crash reporting, analytics on the core loop, CI, and forced-upgrade handling. Each costs a day or two and each saves weeks the first time something goes wrong in the field.
Is fixed price better than hourly for a startup?
For a first version, yes. Hourly transfers all estimation risk to the party with the least information — you. Fixed price forces the scoping conversation to happen before the money starts moving.