How to outsource app development from Germany, from Lastenheft to store release

How to outsource app development: the whole route in eight steps

Outsourcing an app build is mostly about sequencing. If each step is finished before the next starts, the build is predictable; if you skip the first three, the problems arrive in month three instead.

Here is the route a German founder or product owner can follow, whichever supplier they choose. Each step has its own section below.

• Decide what to outsource and which decisions stay with you
• Write a Lastenheft (requirements specification) of a few pages
• Collect itemised quotes against the same document
• Choose the contract type and define formal acceptance (Abnahme)
• Create the repository, cloud and store accounts in your company's name
• Approve screens, then build in sprints with installable test builds
• Accept each milestone against written test cases and pay it
• Release to the stores and switch to a support plan

Timelines follow the same logic: a cross-platform app usually needs 6–10 weeks of build time with us, plus the time you spend on steps 1–4, which is often one to three weeks.

Step 1: decide what to outsource and what stays with you

Outsource the building; keep the product decisions. Whoever pays for the app should own the answers to three questions: who the users are, what they must be able to do on day one, and what success looks like after launch.

A common mistake is to outsource app development and the product thinking in one go, then be surprised when the result reflects the supplier's assumptions. You do not need a full-time product manager, but one person on your side must be reachable, able to decide, and willing to install and test a build every week.

Also decide now what you already have that the app should use: an existing shop, a booking tool, an ERP, a login system, brand guidelines. Reusing a working backend can halve the scope. Rebuilding it inside the app project because nobody mentioned it is one of the most expensive surprises in outsourced projects.

Step 2: how to write a Lastenheft an app team can quote against

A Lastenheft is the client's description of what the app must achieve, not how to build it. Five to ten pages is enough for most apps, and it is the single most useful thing you can do before you outsource app development.

Write it for someone who has never seen your business. Describe the users, what they do today without the app, and what they should do with it. List features as user tasks ("a customer books a slot and gets a reminder") rather than technical wishes ("push notifications"). Mark each feature as must-have or later; that one column is what makes a quote realistic.

Add the constraints: existing systems and their interfaces, data protection requirements from your DPO, accessibility needs, languages, target devices, deadlines tied to real events such as a trade fair. Attach sketches or screenshots of apps you like. Leave out solution choices you are unsure about; a good team will propose them and explain why.

• Goal of the app in two sentences
• User groups and their main tasks
• Features as user stories, marked must-have or later
• Systems to connect, with links to API documentation
• Data protection, accessibility and language requirements
• Target launch date and the reason for it
• What you will supply: texts, images, test accounts

Lastenheft vs Pflichtenheft: who writes which?

You write the Lastenheft (what you need); the supplier answers with a Pflichtenheft (how they will deliver it). The Pflichtenheft turns each requirement into screens, data, interfaces and acceptance tests, and in German practice it often becomes the reference for formal acceptance.

For smaller app projects, a full Pflichtenheft can cost more to write than some features cost to build. A lighter version works well: our itemised estimate lists every feature with a line of description and its price, plus assumptions and open questions. Once you approve it, that document plays the role of the Pflichtenheft, and each milestone's acceptance tests are written from it.

Either way, insist on one rule: anything not in the approved document is a change, and changes get a written estimate before anyone builds them. That rule protects both sides. It keeps the supplier from quietly padding the scope and keeps you from discovering an unexpected invoice for something you thought was included.

Step 3: how to compare quotes when you outsource app development

Compare line by line, not total by total. Two quotes for the same Lastenheft can differ widely because one includes the backend, testing and store release and the other quietly leaves them out.

Ask every supplier to quote in the same structure: features as separate lines, then design, backend, testing, store submission, documentation and support. Ask what is excluded and what they assume you will provide. Quotes vary widely between agencies, freelancers and offshore teams, and we do not publish anyone else's rates; the useful question is what each line contains.

Watch for the questions each supplier asks before quoting. A team that asks about your existing systems, test accounts and data protection requirements has read your Lastenheft properly. A team that sends a price within the hour has probably not.

• Same scope in every quote, or differences stated in writing
• Backend, admin panel and hosting either included or explicitly excluded
• Testing devices and accessibility checks named
• Store submission and review handling included
• Handover documentation described
• Support after launch priced separately

Step 4: Werkvertrag or Dienstvertrag for an outsourced app?

If you are buying a defined app, a Werkvertrag is usually the better fit; if you are buying developer time against a changing backlog, a Dienstvertrag is. Under § 631 BGB the contractor in a Werkvertrag owes the promised work, a result. Under § 611 BGB a Dienstvertrag obliges the provider to perform the promised services, without owing a particular outcome.

For a first release built from a Lastenheft, the Werkvertrag logic protects you: payment is tied to results you can test, and defect rights attach to the delivered work. For later improvements, where priorities shift every sprint, a Dienstvertrag or a monthly scope agreement is more honest, because nobody can promise a result for requirements that do not exist yet.

We work from a written quote that sets out scope, milestones and acceptance tests; if your lawyer wants a formal Werkvertrag on top, we review it. Terms the quote does not cover fall back on our terms. We are not lawyers and do not give legal advice, so the contract wording should always come from or be checked by your own counsel.

What does formal acceptance (Abnahme) mean for an app?

Abnahme is your formal declaration that the delivered work is essentially as agreed. Under § 640 BGB the client must accept work produced as agreed and cannot refuse because of minor defects. Acceptance matters because, in a Werkvertrag, it is typically the point at which final payment falls due and the burden of proof for defects shifts.

§ 640(2) BGB also contains a rule many product owners do not know: if the contractor sets a reasonable deadline for acceptance after completion and the client neither accepts nor refuses within it while naming at least one defect, the work counts as accepted. So when a build arrives for acceptance, test it and reply in writing, even if the reply is a list of defects.

For an app, acceptance works best against test cases written before the build starts. Each milestone gets a short list: the flow, the device, the expected result. You run them on the test build, note anything that fails, and the milestone is accepted once the failures are fixed. Minor cosmetic issues go on a list for the next sprint instead of blocking acceptance.

• Test cases agreed per milestone, before development
• Tested on named devices: at least one iPhone and one Android phone
• Written acceptance or written defect list, never silence
• Minor issues logged, not used to block the whole milestone

Milestone payments in EUR: a schedule that protects both sides

Pay for what you can install. Each milestone should end with a build or document you can check, and its payment should follow your acceptance of it. German law supports this pattern: § 632a BGB lets a contractor request progress payments in line with the value of the work already delivered, and lets the client withhold a reasonable part if that work is not as agreed.

We quote in USD and you pay each milestone in USD or EUR, by Wise, bank wire or PayPal. Paying in EUR through Wise usually shows you the converted amount before you send it. Invoices are issued from India; how your accountant books them, including reverse-charge VAT, is for your Steuerberater to decide.

A typical app has four or five milestones. The exact split is agreed in your written quote, and nothing is billed before you approve it.

Step 5: code ownership from day one when you outsource app development

Create the accounts yourself, before development starts, and invite the team in. That covers the Git repository, the cloud account for the backend, the Apple Developer account and the Google Play Console account. When you outsource app development this way, there is nothing to hand over at the end, because nothing ever left your hands.

Both stores should be enrolled in your company's name. Apple's enrolment page asks organisations for a D-U-N-S number, a legal entity name, a website on your own domain and a work email, and the membership costs US$99 per year. Google Play charges a one-time US$25 registration fee. Google's help centre also notes that personal accounts created after 13 November 2023 must meet extra testing requirements before their apps can go public, one more reason to register as an organisation.

In German law the contract also needs to grant you usage rights to the code, because copyright itself stays with its author. We recommend exclusive rights for all known types of use; the offshore software development guide explains why that wording matters.

Step 6: design approval, sprints and test builds you actually install

Approve the screens first, then build in short cycles. Changing a design in a prototype costs minutes; changing it in finished code costs days.

We start with the key flows as clickable designs. Once you sign them off, development runs in one- or two-week sprints, each ending with a build on TestFlight for iPhone and on a Google Play testing track for Android. Your team installs it, tries the new features on real phones and sends feedback in one list, preferably with screenshots.

Keep feedback in one channel and one list per build. Five people sending separate WhatsApp messages about the same button makes the product owner's job impossible and the developer's even harder. Decide who collects the comments and who decides between conflicting wishes; that is the product owner's most important task during the build.

• One product owner collects and prioritises feedback
• Every build has release notes: what changed, what to test
• Bugs described with device, steps and screenshot
• New ideas go to a “later” list unless they replace something

German legal items to put in the brief before release

List the legal items in your Lastenheft, because they affect the build and are easy to forget until store review. The texts themselves come from your lawyer or legal-text provider; the app must display and respect them.

Consent is the one that shapes the code most. § 25 TDDDG requires consent for storing or reading information on a user's device unless it is strictly necessary for a service the user explicitly asked for. So analytics and marketing SDKs start switched off and wait for the user's choice, which can be changed later in the settings.

The rest is mostly placement and consistency: an Impressum and privacy policy reachable inside the app, account deletion inside the app if users can register, store privacy declarations that match what the app and its SDKs really do, and accessibility for consumer services covered by the BFSG. The app company guide for Germany goes deeper into SDKs, trader details and accessibility.

Step 7: store release and the first week live

Plan the release as a small project of its own. Store listings, screenshots in the required sizes, privacy forms, age ratings, review notes and a test login for reviewers all have to be ready before submission.

We prepare the listings and submit through your accounts, answer reviewer questions and fix anything a rejection points to. German listing texts come from you or your copywriter; we handle the technical side, localisations and sizes. A staged rollout on Google Play lets you release to a share of users first and watch crash reports before everyone updates.

The first week after launch is when real devices reveal what test phones did not. Crash reports, store reviews and support emails are checked daily, and fixes go out as quickly as review allows. Budget a little attention from your side too: someone should read the first reviews and pass on patterns rather than single complaints.

Step 8: the post-launch support plan

Agree the support plan before launch, not after the first crash. An app needs regular updates because Apple and Google release new operating system versions every year and raise their technical requirements for published apps.

With us, the first two months after release are free: bug fixes, small changes, dependency and SDK updates, and help with store questions. After that, maintenance starts at US$120/mo. It covers testing against new iOS and Android versions, framework and plugin updates, certificate renewals and keeping the store privacy declarations current. New features are quoted separately, like the original build.

Whatever supplier you choose, write down what the plan covers, how you report problems and what happens if you stop paying for it. With the code, accounts and documentation in your name, stopping should never mean losing the app.

What does it cost to outsource app development?

With BtechWaleTech a cross-platform app for iPhone and Android starts at US$600, and an app with its own backend and admin panel starts at US$900. The final number depends on your Lastenheft, and each feature appears as its own line so you can move it to "later" and see the effect.

The biggest cost drivers when you outsource app development are predictable: user roles (customer only, or customer plus staff plus admin), a new backend versus an existing API, offline sync, payments and bookings, integrations with ERP or CRM systems, languages, and the depth of design. Compliance work such as consent handling and accessibility testing belongs in the estimate too, not in a surprise invoice.

Running costs come on top of the build: the Apple membership, hosting, push and analytics services, and maintenance after the free period. The app development cost guide for Germany shows sample budgets by app type.

Outsourcing to India from Germany: overlap, calls and the first two weeks

India is 3.5 hours ahead of Germany in summer and 4.5 hours in winter, so your morning and early afternoon fall inside our working day. Calls are in English over video; quick questions go through WhatsApp, answered seven days a week.

Days one to five: a call to walk through your Lastenheft, our written questions, then the itemised estimate within about two working days. After you approve it, you create the repository, cloud account and store accounts and invite us, and we agree the milestone test cases together.

Days six to ten: the first clickable designs for the core flow, a technical plan, and an empty app installed on your team's phones through TestFlight and a Play testing track. That empty build proves the accounts, signing and pipeline work, weeks before anything important depends on them.

There is no office in Germany and there are no visits. Invoices come from India; payments go per milestone in USD or EUR by Wise, wire or PayPal.

Red flags when you outsource app development

Most outsourced app projects that fail show it early. These signs usually appear before signing or in the first fortnight:

• A price quoted without questions about your Lastenheft
• The app to be published under the supplier's store account
• Code shared only as a zip file at the end
• Milestones defined as percentages or hours, not installable builds
• No acceptance tests, or acceptance “by use” without a protocol
• Every change request answered with “no problem”, then invoiced later
• No mention of support after launch or yearly OS updates
• Promises of store rankings or download numbers

And a limit from our side, stated plainly: we build and maintain apps remotely, in English, with three people. If you need German workshops on site or a large team, choose a supplier who offers that.

Worked example: a Leipzig physiotherapy practice outsources a booking app

This is a hypothetical scenario to show the steps in use; it is not a client project.

Say a physiotherapy practice with three locations in Leipzig wants patients to book and move appointments in an app, receive reminders and complete an intake form before the first visit. The practice already uses a scheduling system with an API. Its owner writes a six-page Lastenheft: users, booking rules, reminder timing, the intake form, and a note from the DPO that health data must stay in the EU.

We would reply with questions about cancellation rules and the scheduling API, then an itemised estimate starting from US$600, with separate lines for the API connection, the intake form, reminders and accessibility testing. Because the intake form holds health data, the backend would run in the practice's own EU cloud account, and the DPO would add an AVV and SCCs before we saw any real data.

Milestones might be: approved designs; booking working on test builds; intake and reminders; acceptance and store release. Each would have written test cases the practice manager runs on her own phone. After release, two months of free support would cover fixes, and the practice would then decide whether to continue maintenance from US$120/mo.