How to build an application from scratch - step by step

Application delivery can be divided into seven areas: discovery, scope, design and architecture, iterative build, testing, deployment, and maintenance. They do not always happen linearly, but skipping the goal, scope boundaries, or acceptance criteria raises the risk of costly changes during delivery.

Stage 1. Discovery - why and for whom

Define the problem, the users, the change expected in the business, current process, data, integrations, and risks. The output is a decision document, not only a conversation.

Stage 2. Scope - what belongs in version one, and what does not

Choose the smallest scope that lets a real user complete the key journey and tests the important hypothesis. Distinguish necessary features from later improvements, but do not cut safe data boundaries, appropriate permissions, backups, logs, or real-data tests.

Stage 3. Design and architecture

Agree the main concepts, data ownership, integrations, user roles, interface direction, and non-functional requirements: availability, security, performance, and observability. The purpose is not to predict every table or screen; it is to avoid building current scope on contradictory assumptions.

Stage 4. Build iteratively, not “until it is ready”

Split delivery into working slices. Each slice should have an intended outcome, acceptance criteria, and a demonstration using realistic data. Regular feedback finds misunderstandings while the cost of change is still low. A long period with no usable result is a project risk, not proof of progress.

Stage 5. Testing - not only clicking around

Test the key business journey, permissions, validation, failures, integrations, and use on different devices where relevant. Automated tests protect repeatable logic; exploratory checks reveal situations that were not anticipated. Production-like data volume and edge cases matter, because a system that works on a few records may fail under real conditions.

Stage 6. Production deployment

Prepare the hosting environment, domains, configuration, secrets, database migration, backups, monitoring, alerts, and rollback plan. Deployment is not just copying code to a server. Assign someone to respond when an alert fires and decide how the team will recognise a partial failure.

Stage 7. Maintenance and development

The first release is the beginning of learning. Monitor use, errors, performance, costs, and questions from users. Prioritise the next change by observed value and risk, not only by the longest wish list. Keep dependencies, access, backups, and recovery tests maintained as part of normal operation.

How long does it take and how much does it cost?

Indicative timing and price depend on scope, integrations, data readiness, and the availability of business decisions. Our August 2026 ranges: discovery 3,000–8,000 PLN net for a direction workshop or 8,000–25,000 PLN net for fuller planning; an MVP with one key journey 15,000–35,000 PLN net in roughly 4–6 weeks; larger application work is estimated as a separate project. Fixed price requires defined acceptance criteria and client-side assumptions.

When not to build an application

Do not build one when a process is rare, unclear, or can first be tested manually; when a ready-made system already meets the essential requirement; or when the real issue is an unmade business decision rather than missing software. Building custom software is justified when the problem, users, and advantage of a tailored process are understood.

Frequently asked questions

Does the code belong to us?

Agree this explicitly in the contract, together with repositories, access, documentation, licences, and handover conditions. Ownership wording without operational access is not a useful handover.

Can an application be built without every detail known in advance?

Yes. Set the goal, first-version boundary, risks, and decision process; then refine lower-risk details iteratively. Uncertainty should be visible and managed, not hidden in an unlimited scope.

How do we check whether a supplier can handle production?

Ask what they currently maintain, how they learn of failures, how access and backups work, who writes the code, and what happens at handover. A portfolio alone does not answer those questions.

---

We take projects from discovery through delivery and maintenance. See application development or describe the process you want to improve.