Petadev helps startups and businesses plan and build the first working version of a mobile app. Together we choose the features needed for launch, define the scope of the build, and deliver an app your first users can use to complete real tasks.
If you already know what problem the app should solve, but the feature list keeps growing, it is time to set the boundaries of the first release. The same applies to a new startup and to a new digital service at an established business.
Here, an MVP (minimum viable product) means the leanest version of the mobile app that is already usable. Your first users can complete the task that makes the app worth opening. Real usage and feedback then tell you how to continue.
If it is not yet clear who the product would help and in what situation, that is worth clarifying first. A clickable prototype or a simpler way to test the idea may be enough for the next decision. Not every idea should start with building the mobile app.
What do we plan for the first release?
One user flow that works end to end
We define the one core task the app has to handle well from day one. In a booking app, for example, choosing, booking and confirmation together make a usable flow. A finished calendar on its own is not necessarily enough.
Clear feature boundaries
We sort the tasks into three groups: needed for launch, can be handled manually at first, and can wait until later. Security, proper permission handling and testing of the core flow are part of the plan even for the first version.
The backend and admin tools it needs
We go through what data the product stores, who manages the users and what happens when something goes wrong. The scope of the admin panel is matched to what launch actually requires. We only plan integrations that have a real job in the first release.
A measurable goal for after launch
During planning, we define what results you can learn from. For example: do users get through their first booking, where do they get stuck, and why do they come back? The technical requirements for the chosen measurements are included in the development tasks.
Our own example: what did we leave for later at Ostva?
In Ostva's first version, the marketplace was available through the iOS and Android apps, and the full browser-based marketplace was left for later. The web admin panel was built, because operating the marketplace required it. Developing the mobile app took about five months: a first release can still be complex when the business process needs many parts to work.
The project started as a client engagement. Petadev's founder later joined Ostva as a co-founder.
ERIKA Helps: legal guidance with audio explanations
An accessibility-focused legal help app for iOS and Android. It helps users find their way around the law, and the explanations are also available as audio, so blind and visually impaired users can use it too. We also built a website to introduce the app.
Open Horizon Aviation: crew for line-training companies
A web application connecting line-training companies with pilots and flight attendants. After registration, crew members enter a database that companies can filter to find the right people.
GetFlyMate: cost sharing for pilots building hours
An iOS and Android app where pilots list planned flights and open seats. Passengers browse by destination, date and aircraft and share the cost of the flight.
1We clarify the starting point. Who will your first users be, what problem do they have, and how do they solve it today? We discuss the budget, the planned launch date and any materials you already have.
2We define what goes into the first version. We document the core flow, the user roles, the screens needed and the integrations. Everything that can come later goes on a separate list.
3We design the screens and the schedule. We walk through how the app works using wireframes and UI designs. For the approved scope, we prepare a proposal and a development plan broken into milestones.
4We build and test the app. During development, you can check working parts of the app. Before handover, we test the entire core flow, including important failed and interrupted actions.
5We prepare the launch and what comes next. We match the release to the distribution method you choose. Early usage and business results then shape the next development phase.
What drives the cost and timeline of an MVP?
A simpler mobile app MVP built around one or two main features typically takes us two to six weeks, depending on the technology. This is an indicative range: the exact timeline depends on the user roles, payment flows, external systems and the screens the first release needs. A more complex first version, like Ostva's, can take several months.
The proposal states what we will build, what is left for later and what each milestone delivers. If a new requirement comes up during development, we first agree on its impact on cost and timeline. The effort for a later extension can also depend on how the existing system is built.
Tell us who would use the app, what the most important action in it would be, and whether you already have a tested concept or UI designs. If you know your budget and planned launch date, include those too. With this, we can have a focused conversation about a realistic first release.
Do I need a finished specification for our first conversation?
No. It is enough if you can tell us who the app is for, what problem it would solve and how you imagine the business working. We work out the detailed development tasks together. If you already have a specification or a prototype, we will review that too.
What is the difference between a prototype and an MVP?
A clickable prototype is for trying out the screens and navigation, even without a working backend. A mobile app MVP is already a usable product: the chosen core flow works end to end with real data. The two answer different questions, so the right step depends on where the project stands.
Does the first version have to work on both iOS and Android?
Not always. If your first user group uses known devices, it can make sense to start narrower. If both platforms are needed, we account for that from the planning stage and look at building on a shared codebase.
Can an established business build an MVP for a new service?
Yes. The first-version approach also works in a company setting, for example to test a new customer process or an internal mobile workflow. In that case, the connection to existing systems and the tasks of the employees involved also have to be planned.
Can the first version be developed further?
We plan for the known directions of growth. However, nobody can guarantee in advance that every future business change will be possible without restructuring. We estimate the next development steps based on real experience and the needs at that time.
Who will use and evaluate the first release?
The first user group should be chosen based on the business goal. Building the app does not, on its own, bring customers or market success. So the launch plan should name who is responsible for reaching the first users and processing their feedback, not just for the app. That said, a well-planned MVP can already be ready for market launch and serve its users properly.