App specialists: who you need on an app project, and when

Appspecialisten is Dutch for app specialists, and the plural is the useful part. An app looks like one product from the outside, but it takes several distinct crafts to build and run, and projects tend to stumble when one of them is missing and nobody notices until the week before launch.

This guide describes the roles an app project needs and when each one matters, three team shapes for different budgets, the choice between freelancers, a studio and an in-house team, and a short interview for each role. Small projects combine roles in one person all the time. That's fine, as long as someone knows they're carrying both.

The roles at a glance

Product owner

This is the one role you shouldn't hand over completely. The product owner decides what gets built and in what order, answers the team's questions within a day, and says no to good ideas that don't serve the core task. In a startup it is often the founder. When an agency provides one, keep a decision-maker on your side who meets them every week.

UX and UI designers

UX design covers how the app works: the flows, the research, the prototypes and the tests with real users. UI design covers how it looks and feels: type, color, components and the details that make an app feel at home on each platform, guided by Apple's Human Interface Guidelines and Google's Material Design. On small projects one person does both. Hire for whichever half your app needs more, and check that accessibility (text scaling, contrast, screen reader labels) is part of their normal work rather than a final pass.

Mobile developers: iOS, Android or cross-platform

Native apps are written in Swift for iOS, often with SwiftUI, and in Kotlin for Android, often with Jetpack Compose. Cross-platform teams share most of their code with Flutter, React Native or Kotlin Multiplatform. That decision shapes the whole team, so settle it early; our guide to choosing a cross-platform framework lists the questions. Even a cross-platform team needs someone who knows each platform well: signing, permissions, background work, store review and the native code you'll eventually need.

Backend developer

The backend developer builds the APIs, the database, sign-in, push notifications and the admin tools someone will need for support. Mobile adds a constraint that web projects rarely face: older versions of the app stay installed long after you release a new one, so the API has to keep working for them while the newest version moves on. Plan versioning from the first release. Backend-as-a-service platforms can replace much of this work in a first version, but someone still has to own the data model and the security rules.

QA tester

Developers test their own code; a tester finds the paths nobody planned. A good tester writes test plans from the user's point of view, keeps a spread of real devices, runs a regression check before each release and knows what store reviewers tend to reject. On small projects, a few days of outside testing before each major release is a sensible minimum.

DevOps and release

Someone has to own the path from a commit to a build in testers' hands and then in the stores: continuous integration, code signing, version numbers, distribution through TestFlight and Google Play's testing tracks, crash reporting and store submissions. On a small team a developer does this part-time, which works until the whole setup lives on a single laptop. Ask for it to be automated and written down early.

ASO and marketing

This role covers the listing, the keywords, the screenshots, the launch plan and, later, paid campaigns. Bring this person in a few weeks before launch, not the evening before, and give them a clear position to work from. Our guide to finding the angle before you promote an app covers what they'll need from you.

Team shapes for three budgets

These shapes illustrate how roles combine at different sizes. They are not rules, and the same app can be built well by different combinations. Read them as a starting point for a conversation with a partner or for a hiring plan.

To turn a shape into hours, run your feature list through the app development cost calculator, or read our line-by-line look at what an app really costs.

Freelancers, a studio or in-house

Each option fits a different situation, and many projects combine them over time.

Freelancers give you direct contact with the person doing the work and the flexibility to hire exactly the skill you need for exactly as long as you need it. The cost is coordination. With three freelancers you are the project manager, and if one of them falls ill the week before launch there may be no one to step in. Freelancers suit projects with a strong product owner and a clear plan.

A studio brings a complete team, an established process and continuity when someone leaves. You pay for that overhead, and you have less say over who works on your project from week to week. Studios suit a first version built by people who have shipped many apps, especially when you have no technical staff of your own.

An in-house team keeps the knowledge inside your company and can cost less over several years if the app is the core of the business. Hiring is slow, though, and some roles (a release engineer, an ASO specialist) are hard to fill when the need is part-time. A common pattern is a studio for the first version and an in-house team afterward, with the handover written into the contract from the start. Our guide to choosing an app agency or studio covers what that handover should include.

Interviewing each role briefly

You don't need a long process to learn a lot. A half-hour conversation built around one question per role, followed by a small paid test task for longer engagements, tells you most of what a portfolio won't. Ask about something they shipped, then listen for specifics.

Pay for test tasks, keep them small (a few hours, not a week), and make them close to real work: review a screen, fix a known bug in a sample project, rewrite the first lines of a store description. Unpaid spec work tends to filter out the experienced people who have other offers.

One list before you hire

Before you hire anyone, copy the role table into your own project plan and write a name next to each row, even when several rows carry the same name. Then look at the rows that are still empty. Those are the ones that surface in the week before launch, so decide now whether to fill them, combine them or consciously go without.