Powstania Warszawskiego 15
31-539 Kraków
Most first versions are built by four people, not ten. What decides the shape of the team is the number of user roles, whether there is a backend, and how much of the product is still undecided.
Four roles are required on any build: someone who owns product decisions, a designer, at least one mobile developer, and quality assurance. A backend developer joins as soon as data is shared between users. Everything else is added when the product's complexity demands it.
Roles are not people. On a small build one person often covers product and project management, a designer works part time after the first weeks, and quality assurance runs in bursts before each release. That is normal and it is how a four person team delivers a real product.
What is not normal is leaving a role unfilled and hoping. An app with no product owner drifts. An app with no quality assurance ships defects to real users. Both cost more than the role would have.
Below is every role that appears on mobile projects, what it owns, and the point at which it stops being optional.
Owns what gets built and in what order, resolves conflicts between stakeholders, and decides what leaves version one. On client side projects this is often the client, not the supplier.
Needed from day one. The project needs one person who can make a decision stick, not a committee.Turns an existing operation into written requirements: who does what today, which exceptions exist, which rules the business actually follows rather than the ones in the manual.
Worth having when the app replaces a complex internal process or when several departments disagree on how the work is done.Designs the flows first and the interface second. On a well run project the designer spends more time on states and edge cases than on visual polish.
Heaviest at the start, then part time through the build for the screens that change.Builds one codebase that runs on iOS and Android. Strong choice for products with a custom interface and heavy data driven screens.
Needed from the first development week. See hiring Flutter developers for what to look for.The same single codebase approach in the JavaScript ecosystem, which suits teams who already have web engineers and shared tooling.
Alternative to the above, not an addition. See hiring React Native developers.Platform specific work: deep hardware integration, complex background behaviour, or an app whose whole value depends on platform features.
Occasionally needed alongside a cross platform team for one specific area rather than for the whole product.Data model, API, authentication, admin tooling and integrations with other systems. Everything the app depends on and users never see.
Needed as soon as data is shared between users or synchronised across devices. Only a genuinely local app avoids it.Tests across devices and operating system versions, runs regression before each release, and checks the paths users take rather than the ones the team expected.
From the first working build, part time. Full time once there are several roles and money is involved.Build pipeline, environments, release automation, monitoring and store submission plumbing.
A few days of setup at the start on a standard project. A dedicated role only on larger systems with multiple environments.Plans, coordinates and keeps communication moving between the client and the delivery team.
On a small build the product owner covers this. It becomes its own role when more than a handful of people are involved on both sides.Teams grow in three recognisable shapes. Each one is triggered by something specific in the product rather than by ambition or budget.
A product owner, a designer part time, one or two mobile developers, backend as needed, quality assurance part time.
Fits a single main user role and one platform pair. This is what most first releases actually run on.Adds a dedicated backend developer, full time quality assurance, and a project manager once coordination stops fitting into one person's week.
Triggered by a second user role, an admin panel used daily, or the first real integration.Adds a business analyst, dedicated DevOps, and sometimes a native specialist for one part of the product.
Triggered by regulated data, several integrations, or an operation where downtime costs money.The useful test is not how big the product feels. It is whether one person can still hold the whole thing in their head. When they cannot, the next role is worth its cost.
In house makes sense when the app is the business and will keep changing for years. Freelancers work when your scope is small and you can manage the work yourself. An agency makes sense when you want the whole team and the delivery risk in one place.
The honest way to choose is to ask who owns the outcome if something breaks between two people's work. With an agency that is written into the contract, along with acceptance and warranty terms. We work fixed price against an agreed scope, which is explained on our fixed price app development page.
A mixed model is also common and often sensible: an agency builds version one, then a hired developer takes over maintenance with the agency available for larger changes. What matters is that the handover is planned rather than improvised.
Two things, regardless of which model you choose: one person who can make decisions, and someone who knows how the work is really done today.
Four roles, typically covered by three to five people on a first version: product, design, mobile development and quality assurance, with backend added as soon as data is shared between users. Larger teams follow from more user roles and more integrations, not from a bigger ambition.
For a small, single role product, sometimes. What one person cannot do is test their own work objectively or design the product while building it. Even a solo build needs someone else looking at both.
Not with a cross platform codebase. One Flutter or React Native developer covers both platforms, which is why cross platform teams are smaller. Native specialists are added only for specific hardware or background behaviour.
Per hour, yes. Per delivered product, often not, because the coordination between specialisms is included rather than falling to you. The comparison to make is total cost including your own time and the risk of the work not fitting together.
When the app is core to the business and will keep changing for years, and when you can hire more than one person. A single in house developer with no team around them becomes a single point of failure for a product the business depends on.
You should, in full, and it belongs in the contract along with repository access, credentials and acceptance terms. Ask about this before signing rather than at handover.
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Tell us what the product has to do and who uses it. We will map the roles it genuinely requires, which of them can be part time, and what you would keep on your side.
Book an intro call30 minutes, no preparation needed.