A custom mobile app project goes through four phases: diagnosis, design, development and optimisation. Each one involves a different decision: whether an app is needed at all, what goes into the first version, what technology it will be built in and who will maintain it after launch. Below we describe what is produced at each stage and where projects lose the most time.
Diagnosis: is a mobile app needed?
The first question we ask at the start concerns the channel itself. A native app makes sense when the product uses phone features (camera, push notifications, offline work, Bluetooth) or when users come back to it several times a week. If contact with the product is infrequent and the content can be served in a browser, a responsive web app will be cheaper to build and maintain. This decision costs one conversation. Made after a year of work, it costs the entire development budget.
Outcome: a decision on whether to build a mobile app, a web app, or both channels in an agreed order.
Product workshop
Once the channel is chosen, we define the scope of the first version in a product workshop. We work with three tools:
- personas, that is, a description of user types, their goals and constraints,
- user story mapping, that is, a map of user activities on which you mark what goes into the first version and what waits for later ones,
- customer journey, that is, the path from first contact with the product to regular use.
The workshop settles disputes that would otherwise return halfway through development: which user group matters most and which features can be dropped. The person responsible for the budget gets a scope that can be priced and defended in front of the board. For products with a complex business process, an Event Storming workshop is added.
Outcome: a prioritised list of first-version features, personas and a map of user journeys.
Design: from flows to a prototype
We start designing with flows, and colours and typography come later. A user flow shows the user’s successive steps and the places where they can get lost. On that basis we create wireframes, which are skeleton versions of screens without a graphic layer. On wireframes a layout change takes an hour, in code a few days.
The next step is the interface design: typography, colour, components and screen states (empty, loading, error). For larger products a design system is created straight away, that is, a library of components and rules used by designers and developers. The earlier it exists, the fewer corrections there are with every further feature.
Before development we build a clickable prototype and show it to users. A few conversations with the prototype in hand reveal problems that the team cannot see because it knows the product too well. A prototype at Squares costs from PLN 8,000 net, and the amount depends on the number of screens and the scope of validation.
A decision on accessibility is also made at this stage. From 28 June 2025, some digital services for consumers, including e-commerce and banking, must meet the accessibility requirements arising from the European Accessibility Act. Contrast, touch target size and screen reader support are cheaper to design in from the start than to fix after an audit. We describe the scope of the obligation in the article on who the EAA applies to.
Outcome: a design of all screens of the first version, a prototype checked with users and a specification for the development team.
Development: technology, short cycles and testing
Choosing the technology
We build mobile apps in Flutter. It is a Google toolkit that lets you build an Android and iOS app, as well as a web and desktop version, from a single codebase. One codebase means one team and one list of fixes instead of two. Native technologies (Kotlin, Swift) are chosen when the product depends heavily on the features of a specific system or the company already has a native team. We describe the selection criteria separately in the article on mobile app technologies.
Building in cycles
Before the start we agree the scope, the order of work and the acceptance criteria. We build in two-week cycles, and each ends with a review of a working part of the product. We introduce changes of priority between cycles, so they do not interrupt work in progress. After each review the Product Owner knows how much of the scope is done and how much budget is left.
Testing
We test every part manually and automatically before it reaches users: features, performance, security and conformity with the design. A bug found before release costs an hour of work. The same bug after release also costs store ratings and customer support tickets. How to give selected people a trial version before release is described in the article on beta testing in TestFlight and Google Play.
Publishing in the stores
Publishing in the App Store and Google Play involves its own formalities, which are worth starting earlier than in the last week of the project. A company enrolling in the Apple developer programme must provide the D-U-N-S number assigned to its legal entity. On top of that come developer accounts, descriptions, screenshots and data declarations. Account verification and the first app review can push back the launch if they are left until the end.
Outcome: a working app in both stores, built according to the design and released in stages.
Optimisation: what happens after release
Release opens the longest phase of the project. After launch we collect data on behaviour and user feedback, fix bugs and plan further features. The client has access to a ticket panel in which they see reported bugs and suggestions, and the status of work on them. We carry out development within an agreed pool of hours per month, so the cost is predictable.
A mobile app also needs ongoing technical support: new versions of Android and iOS, changes to store requirements, library updates. When sales or customer service depend on the product being available, the response time to an outage is worth putting in the contract. The Maintenance and SLA service is for this, billed as a fixed monthly fee.
Outcome: a product monitored and developed on the basis of data, with an agreed response time for outages.
How much does a custom mobile app cost and how long does it take?
The cost depends above all on the scope of the first version: the number of screens, integrations with other systems, user roles and security requirements. At Squares a prototype costs from PLN 8,000 net, and development starts at PLN 20,000 net. We price development up front or bill it for time worked at PLN 250 net per hour. The timeline is known after the preparation stage, in which we agree the scope and acceptance criteria. We break down the factors affecting the price in the article on the cost of a mobile app.
The budget is most often exceeded in projects where diagnosis was skipped. The scope then grows during development, and each change is priced separately.
Mobile apps at Squares
We design and build custom mobile apps in one team, from the workshop to maintenance, so design decisions do not get lost on the way to code. The scope and the way of billing are described on the Development service page. Let’s start with a conversation about the scope: let’s talk about your project.
Frequently asked questions
How long does it take to build a custom mobile app?
The time depends on the scope of the first version and is known after the preparation stage, in which we agree the scope and acceptance criteria. Building runs in two-week cycles, and each ends with a review of a working part of the product. The launch can be pushed back by formalities in the App Store and Google Play, which is why they are started earlier than in the last week of the project.
Where do you start a mobile app project?
With diagnosis, that is, the question of whether a mobile app is needed at all or whether a responsive web app is enough. The next stages of building a mobile app are a product workshop, in which the scope of the first version is defined, design with a clickable prototype, development and optimisation after release. Projects without diagnosis most often exceed their budget.
