Getting an App Built: The Complete Guide for SME Decision-Makers Who Can't Afford Costly Mistakes

Imagine hiring an architect without telling them how many rooms you need. No floor plan, no brief on how the space will be used — just: "Build us something nice." Sounds absurd? That's exactly what happens every day in app development. A managing director has an idea, calls an agency, and six months later wonders why the budget is blown and the result misses the mark.

Industry studies have consistently shown the same picture for years: around 30% of all IT projects fail completely, and another 50% are delivered over budget, behind schedule, or with reduced functionality. The reason is almost never bad code. It's unclear requirements, inadequate preparation, and a fundamental misunderstanding of what the client's role in a software project actually is.

This article is not a developer's guide. It's not about programming languages, frameworks, or server architecture. This is a buyer's guide. It's written for managing directors, department heads, and decision-makers at SMEs who want to commission an app — and want to make sure the project succeeds. Not in spite of their own preparation, but because of it.

According to the Bitkom Annual Press Conference 2026, Germany's ICT sector is growing to €245 billion in revenue. Digitalization is no longer a future trend — it's the present. Companies that aren't building digital touchpoints right now are losing ground to competitors who already have. An app is often the most visible, most tangible step in that direction. But only when it's properly planned.

The Right Question First: Do You Actually Need an App?

Before you invest a single euro in development, you need to honestly answer an uncomfortable question: Does an app actually solve a concrete business problem — or is it a "wouldn't that be cool" project?

In our initial consultations at Golle IT, we regularly encounter clients who arrive with a technology solution before they've defined the problem. "We need an app" is not a brief. It's a wish. The questions that actually matter are:

• What business problem needs to be solved? Is this about customer acquisition, process optimization, internal communication, or opening a new sales channel?
• Who are the users? Your customers? Your employees? Both? The answer determines everything — from platform choice to design.
• What should the app do — and what should it explicitly not do? Setting boundaries is just as important as defining features.
• Are there alternatives? Sometimes a well-built web app, an optimized online store, or even an automated workflow is the better solution.

When an App Actually Makes Sense

A native or hybrid app is worth the investment when at least one of the following applies: You need access to device features (camera, GPS, push notifications). Your users need to open the application quickly and frequently — not through a browser. You want to create a brand experience that goes beyond a website. Or you're digitizing a process that happens on the go (field service, logistics, on-site customer support).

If none of these apply, an app may not be the right investment. A good development partner will tell you that honestly. A bad one will send you a proposal anyway.

What You Need to Know Before Your First Agency Meeting

That first conversation with a development agency often determines the entire trajectory of the project. Not because contracts are signed there — but because it's where expectations, budget, and timeline are set. The better prepared you are, the more productive that conversation will be.

Define Your Target Audience and Usage Context

Describe your users as specifically as possible. "Our customers" isn't enough. Better: "Master tradespeople between 35 and 55 who manage jobs on-site and primarily use Android devices." The more precise the picture, the more accurate the outcome.

Ask yourself: When and where will the app be used? On a reliable Wi-Fi connection at a desk, or with spotty reception in the field? For two minutes on the go, or for thirty minutes of focused work? This context shapes technical decisions that are expensive to reverse later.

Separate Core Features from Nice-to-Haves

Create two lists. List one: What must the app be able to do on launch day to fulfill its purpose? List two: What would be great to have eventually, but isn't essential? This distinction is your most important protection against scope creep — the uncontrolled expansion of requirements during development.

A real-world example: A client came to us wanting an appointment booking app. Over the course of discussions, a chat feature, payment system, review portal, and loyalty program were added. A €40,000 project became a €120,000 project. Not because the agency was upselling — but because the scope was never clearly defined.

Prepare Your Platform Decision

iOS, Android, or both? Or is a web app sufficient? This decision depends on your target audience, not personal preference. In Germany, Android holds over 60% market share. If your users are primarily iPhone users (as is often the case in certain B2B sectors), an iOS-first approach may make sense.

Cross-platform technologies like Flutter or React Native allow you to serve both platforms from a single codebase — a solid compromise for many SME projects. But this decision also has implications for performance, maintenance, and cost that your development partner should walk you through.

Set a Realistic Budget

App development costs in the DACH region vary widely: from a few thousand euros for simple solutions to six-figure sums for complex, cross-platform applications. A basic informational app with a handful of screens is a fundamentally different investment than a data-intensive platform with user accounts, payment functionality, and backend integrations.

The real problem isn't the cost — it's the cost surprises. Projects that start without a clear scope almost always run over budget. Going into a conversation with a realistic budget range means a reputable agency can give you an honest assessment of what's achievable within that range — and what isn't.

Clarify Timeline and Internal Resources

Many SMEs underestimate how much of their own time a development project requires. You're not just the client — you're an active participant. Feedback rounds, approvals, testing phases, content delivery: all of this takes time and requires a dedicated person on your side.

Clarify upfront: Who is the internal point of contact? Who has decision-making authority? How quickly can approvals be given? A project that waits a week for client feedback every two weeks will take twice as long as planned.

The Scope Document: Why It's Your Most Important Asset

A scope document isn't a bureaucratic hurdle — it's your insurance policy against misunderstandings, budget blowouts, and disappointment. It describes what the app should do, from your perspective as the client. Not how it will be built technically — that's the agency's job (and is captured in the technical specification).

What Belongs in a Good Scope Document?

• Background: Why is the app being built? What problem does it solve?
• Target audience: Who will use the app? In what context?
• Functional requirements: What should the app specifically be able to do? (List each feature as a separate item)
• Non-functional requirements: Performance expectations, security requirements, supported devices and OS versions
• Integrations: Does the app need to communicate with existing systems? (CRM, ERP, inventory management, payment systems)
• Constraints: Budget, timeline, regulatory requirements (GDPR!)

The Scope Document as a Negotiating Foundation

A clearly written scope document fundamentally changes the dynamic between client and agency. Instead of "put together a proposal for us," you're saying: "Here's what we need — what will it cost, and how long will it take?" You can compare proposals on equal footing. You'll immediately notice if an agency interprets a feature differently. And you have a document both parties can refer back to when questions arise.

No scope document needs to be perfect. It needs to be complete enough to serve as a working foundation.

If the exact feature set isn't finalized yet, we at Golle IT are happy to work through requirements and priorities together in structured workshops — because a solid scope document benefits both sides.

Technical Realities That Catch Clients Off Guard

Some aspects of app development are invisible to first-time clients — until they suddenly become a problem. Here are the four most common surprises we encounter in practice.

App Store Compliance: The Hurdle After Development

Many clients assume the app is "done" when the developer hands it over. In reality, that's when another process begins: publishing to the app stores. And that process is anything but automatic.

According to Apple's 2024 Transparency Report, nearly 1.93 million app submissions were rejected — for violations of quality, security, or business guidelines. These aren't edge cases. Apple reviews every submitted app for privacy compliance, content policies, technical stability, and correct implementation of in-app purchases. Google has comparable processes.

What this means for you: App Store compliance needs to be considered from day one. Privacy policies, age ratings, accessibility standards — all of this must be addressed before launch, not after. Ask your agency explicitly: "Who handles the App Store submission, and what do you need from us to do that?"

GDPR: Not a Checkbox, but a Design Decision

For companies in the DACH region, data protection isn't an optional feature — it's a legal requirement. And it needs to be built in from the very first concept sketch, not bolted on as an afterthought.

From our experience at Golle IT, these are the questions that must be answered before a single day of development begins:

• What user data will be collected? Name, email, location, usage behavior?
• Where will the data be stored? EU-based servers are generally required for GDPR compliance.
• Does the app need a privacy policy? Yes, always. And it must be specific to the app — not simply copied from your website.
• Is a data protection officer involved? Above a certain company size or when handling sensitive data, this is mandatory.
• Consent management: How will you obtain user consent? How can users request deletion of their data?

For Swiss clients, the new Federal Act on Data Protection (nFADP), in force since September 2023, adds its own requirements. An experienced development partner knows these distinctions and accounts for them in the architecture.

Maintenance Costs: The Budget Line Almost Nobody Plans For

Here's a figure we know from our own project experience — and one that aligns with industry standards: Plan for 15–20% of the original development cost per year for maintenance, updates, and operations.

For an app that cost €80,000 to build, that's €12,000 to €16,000 annually. That covers security updates, adaptations to new OS versions (Apple and Google both release major updates annually), bug fixes, server operations, and minor feature enhancements.

Failing to budget for this means you'll have an outdated, potentially insecure app within two years — one that, in the worst case, gets pulled from the App Store. Maintenance isn't a luxury — it's how you protect your investment.

Platform Fragmentation: Not Every App Runs the Same Everywhere

Android devices come in hundreds of variations with different screen sizes, processors, and OS versions. Even within iOS, there are meaningful differences between an iPhone SE and an iPhone 16 Pro Max. An app that looks perfect on the developer's test device is not finished.

Ask your agency: Which devices will be used for testing? Which OS versions will be supported? What happens when Apple or Google releases a new major update?

Choosing the Right Development Partner

A growing market means more providers — and more opportunities to end up with the wrong one. With 1.36 million people employed in Germany's ICT sector, the options are plentiful. Here are the criteria that actually make a difference in practice.

Review Portfolio and References

Don't just look at what an agency has built — ask who they built it for. Industry experience matters. An agency that has already developed apps for SMEs in your sector will understand your challenges faster than a generalist. Ask for specific reference clients you're allowed to contact.

Evaluate Communication Before Technical Skills

As a non-technical buyer, you're not well-positioned to assess an agency's technical competence directly. What you can assess: How does the team communicate? Are your questions answered clearly, or buried in jargon? Do they respond promptly? Do they listen, or do they immediately go into sales mode?

A good development partner asks more questions in the first meeting than they answer. They want to understand your problem — not pitch their solution.

Recognize the Warning Signs

Be skeptical of:

• Proposals without a discovery phase: Anyone who quotes you a fixed price without thoroughly understanding your project will either renegotiate later or cut corners on quality.
• Unrealistically low prices: If one proposal comes in 70% below the others, something is off. Either the effort has been underestimated, or quality will suffer.
• Lack of transparency: A reputable partner will explain how the price is structured, what assumptions underlie it, and what happens if requirements change.
• "We do everything" promises: Specialization is a quality indicator. An agency offering apps, websites, SEO, social media, and drone video is rarely excellent at all of them.

Contract Terms: What to Watch For

Before signing, clarify: Who owns the source code after the project is complete? What happens if the engagement ends early? Which deliverables are included in the fixed price, and which are billed by the hour? Is there a warranty period after launch?

These aren't impolite questions — they're professional ones. Any reputable agency will answer them willingly.

The Typical Project Process: What to Expect

A transparent process builds trust on both sides. Here's how a typical app project unfolds at Golle IT:

1. Discovery Phase (2–4 Weeks)

Requirements are captured in detail, target audiences are analyzed, and technical feasibility is assessed. The phase concludes with a concept document that both parties sign off on. This phase takes time — but saves multiples of that time during development.

2. UX/UI Design (2–4 Weeks)

Wireframes and clickable prototypes show how the app will look and feel — before a single line of code is written. Changes at this stage are still inexpensive. After development begins, every design change carries a cost.

3. Development (6–16 Weeks, Depending on Scope)

The actual programming, ideally in agile sprints with regular progress reviews. You see the progress every two weeks and can provide feedback early.

4. Testing & Quality Assurance (2–4 Weeks)

Systematic testing across different devices, operating systems, and conditions. This includes usability testing with real users — a step many projects skip and later regret.

5. Launch & App Store Submission (1–2 Weeks)

Publication in the App Stores, including all compliance requirements. Monitoring during the first days, with rapid response to any issues that arise.

6. Maintenance & Ongoing Development (Continuous)

Regular updates, security patches, and adaptations to new OS versions. And: the gradual implementation of the features from list two — the nice-to-haves that were intentionally left out of the first release.

Your Checklist: 12 Questions Before Your First Agency Meeting

Print this list. Answer each question in writing. If you're uncertain about more than three items, invest another week in preparation — it will pay off.

1. ☐ What specific business problem does the app solve?
2. ☐ Who are the primary users — and in what context will they use the app?
3. ☐ What 3–5 core features must the app have at launch?
4. ☐ Which features are nice-to-haves for future versions?
5. ☐ iOS, Android, or both? (Based on your target audience, not gut feeling)
6. ☐ Does the app need to integrate with existing systems? (CRM, ERP, accounting)
7. ☐ What budget is realistically available — including a maintenance reserve?
8. ☐ Who is the internal project owner with decision-making authority?
9. ☐ What user data will be collected, and where should it be stored?
10. ☐ Is there a target timeline — and is it realistic?
11. ☐ Who will own the source code after the project is complete?
12. ☐ Is an annual maintenance budget planned (15–20% of development costs)?

The Next Step Is Yours

Commissioning an app is an investment — in your customer relationships, your processes, or your business model. Like any investment, it deserves careful preparation. The good news: you don't have to figure it out alone.

A good development partner guides you from the first idea to the finished product — and beyond. They help you ask the right questions before they start coding the answers.

Have an app idea and want to know whether — and how — it can be realized? Talk to us — no commitment, no pressure. At Golle IT, we advise SMEs across the DACH region from strategy through to implementation. Not a sales pitch, but an honest initial conversation where we work out together whether an app is the right next step for your business.