Powstania Warszawskiego 15
31-539 Kraków
Nine stages, each with one output and one condition for calling it finished. Written from delivered projects, including the parts that go wrong and the ones that only surface once real people use the product.
Nine: discovery, scope definition, design, technical architecture, development, quality assurance, store submission, launch, and post launch improvement. Each has an owner and a finish condition. Work that skips a stage does not remove it, it moves it later at higher cost.
The stages are not equal in length. Discovery and scope take days to a few weeks, development takes most of the calendar, and store submission takes as long as the client's accounts and the reviewer's questions allow. Timelines for a first release are covered on our MVP cost by app type page.
Understanding the business problem, the operation as it works today, and what has to change once the product exists. A supplier who asks mainly about technology here rather than about your business and the value at stake is a warning sign worth taking seriously.
Turning the understanding into a version one that can be built and priced: roles, journeys, what is included and what is deliberately excluded. This is where the fixed price comes from.
Flows first, interface second. The work that matters is the states each screen needs: loading, empty, error, no permission, offline. Skipping states is the most common reason design gets reopened during development.
Data model, framework choice, how the app behaves without a connection, how it synchronises, where data lives, and which third party services are used. Decisions here are expensive to reverse later.
Built in iterations, with something demonstrable at the end of each. The client sees working software regularly rather than a status percentage, which is the only reliable way to catch a misunderstanding early.
Testing across devices and operating system versions, regression before each release, and checking the paths users actually take. Runs alongside development rather than after it.
Store listings, privacy declarations, review notes and test accounts, then the review itself. Apple checks whether payments should be running through in app purchases, and sometimes needs the business model explained. That is resolvable through communication, and it is predictable for marketplace, booking and subscription products.
Getting the product into real hands, often a group at a time rather than everyone at once. Monitoring and crash reporting go live before the users do.
Fixing what real use exposes, plus operating system updates and store policy changes. Delivery itself is closed formally by signing an acceptance protocol, and on larger contracts we provide a one year warranty on the software.
Rarely the code. In our projects the recurring causes are late access to third party services and store accounts, decisions waiting for approval, design changes arriving after development started, and integrations that depend on someone outside both teams.
The first six are avoidable with preparation. The seventh is not, and a good plan reserves room for it instead of pretending it will not happen.
Three things: decide, supply access, and put the product in front of real users. Availability matters more than hours. A project rarely needs a lot of the client's time, but it needs it at the right moments.
What each stage asks of the client side is covered in more detail in working with an app development agency.
Usually days rather than weeks for a straightforward app. What extends it is a business model the reviewer questions, most often around whether payments should run through in app purchases. Plan for a round of questions on marketplace, booking and subscription products.
Partly. Architecture and backend work can begin while design continues, and that overlap is normal. What does not work is building screens whose flows are still being debated, because the work gets done twice.
The client owns them, which is the right arrangement because the accounts and the published apps stay yours. The supplier is given access. Start this early, since it is the delay we see most often.
By signing an acceptance protocol confirming that the agreed scope was delivered. On larger contracts we also provide a one year warranty on the software, so defects in agreed scope remain our responsibility.
They are estimated and agreed as changes rather than absorbed silently. Some change is inevitable, because real use exposes things no specification could contain. The discipline is naming it as a change rather than letting the scope drift.
Watch crash reports and the paths users actually take, then fix what they hit. The first weeks of real use produce more useful product information than the whole build did.
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 where you are, whether that is an idea, a scope document or a half built app. We will walk through the stages ahead, what each one needs from you, and where the risk sits.
Book an intro call30 minutes, no preparation needed.