Skip to main content

At every stage, you know what is being designed and developed.

We divide the project into clear stages and deliverables so progress is more than a general status report. At agreed intervals, we share something you can review, completed work, open decisions, and possible obstacles. That gives you time to see the results, provide feedback, and make informed decisions before the project ends.

The details are adapted to each project's size and type. A company website, mobile app, and business system may have different schedules and deliverables, but the same principle applies: clear scope, responsibilities, decisions, and progress.

Team collaboration, design review, and project milestone approval

The project journey

Four clear stages, from understanding the problem to launch and continued development

Each stage has a defined goal, deliverable, and decision point. We move on after reviewing the outcome and securing the necessary approvals. This helps identify uncertainty early and discuss significant changes before they consume substantial time and money.

First, we understand the problem, users, and goal

We discuss your business, users, current processes, existing problems, and the outcome you expect. Where needed, we include the perspectives of key people involved in the product, rather than relying on guesses or scattered requests. By the end, we should share an understanding of the problem, target users, priorities, constraints, and initial success criteria.

If much remains unclear, this may be a separate phase. Its purpose is to produce a dependable estimate and reduce the risk of starting development with undefined requirements.

Understand users and identify the core problem
  • Deliverable: a definition of the problem, users, and intended outcome
  • Deliverable: first-version scope and priorities
  • Decision: approve the approach, revise the scope, or investigate further

We review the product's structure and core experience before development

We design the main user journeys, information structure, key screens, and core tasks. Depending on the project, this may include wireframes, a clickable prototype, interface designs, or a technical architecture plan. Reviewing and adjusting major decisions now is usually easier and less expensive than changing them after full development.

A prototype is not necessarily the final product or production-ready code. It builds a shared understanding of the user experience, feature scope, and technical approach before development begins.

Review and try the design before coding
  • Deliverable: user journeys and a prototype of key areas
  • Deliverable: technical plan, data structure, and infrastructure needs
  • Decision: approve the design and scope to begin development

We build step by step and share progress at defined intervals

Development follows agreed priorities and stages. At defined intervals, we share completed components or a reviewable version so you can see the real progress and give feedback before changes accumulate. Testing, bug fixes, and technical or operational documentation happen alongside development as appropriate to the project.

Feedback within the approved scope is considered as part of the relevant stage. Requests that change features, logic, or project scope are assessed for their impact on timing, cost, and technical dependencies before implementation, then added to the plan after agreement.

Build, test, and share versions you can review
  • Deliverable: reviewable versions or components at each stage
  • Deliverable: testing, bug fixes, and required documentation
  • Decision: approve release readiness or continue refinements

We launch, hand over, and plan what comes next

Once the ready version is approved, we release or deploy it according to the plan. We hand over the necessary information and access and, where needed, train the relevant members of your team to use or manage the product. We review the product during the initial launch period, and bug fixes, maintenance, and future development continue under the agreed terms.

Post-launch support scope and duration, response times, infrastructure maintenance, and new features are defined in each project's proposal or contract. Future versions are best planned using user feedback, usage data, and real business priorities.

Launch the product and support the next steps
  • Deliverable: a release-ready version or production deployment
  • Deliverable: agreed handover, training, and documentation
  • Decision: a plan for support, maintenance, and future versions

Communication and reporting

A progress report should be something you can verify, not just a general statement.

We agree on communication and delivery intervals at the start. Reports are as brief, clear, and grounded in visible results as possible. Important decisions, scope changes, obstacles, and anything affecting time or cost are recorded in writing to prevent differing interpretations.

Steady progress also depends on receiving necessary information, access, content, approvals, and feedback on time. If an important client decision or input is delayed, we explain its effect on the schedule clearly.

You try the results

At agreed times, we share completed work or a prototype for you to review and comment on.

You know where things stand

We explain what's done, what's being built, and which decisions we need to move forward.

We agree before making changes

If a suggestion affects timing or cost, we discuss the reasons and options with you before implementing it.

Managing changes

Change is natural. What matters is understanding its impact before implementation.

New needs may emerge or business priorities may shift during a project. We first assess a new request's necessity, technical dependencies, and effect on the agreed scope. If it falls outside the current scope, we agree its estimate and schedule with you before implementation.

Refining agreed work

We review the feedback needed to complete that work and handle it through the relevant stage's process.

Adding a new feature

We first estimate the feature's timing, cost, and technical impact, then add it to the plan after both parties agree.

Changing priorities

In a flexible engagement, we can reorder future work once we've clarified the effect on delivery and scheduling.

Engagement models

The engagement model should reflect how clear the requirements are and how much the project may change.

One contract model doesn't suit every project. A clearly scoped project can be delivered against agreed outputs, while an evolving product needs ongoing capacity and flexible priorities. If there isn't enough information for an estimate, a discovery and project-definition phase is the better starting point.

Defined-scope project

Suited to projects whose main requirements, deliverables, and constraints are reasonably clear. Scope, stages, timing, pricing, and change terms are documented in the proposal or contract.

This model isn't suited to large, frequent changes. Out-of-scope features are added after separate assessment and agreement.

Ongoing collaboration for a growing product

Suited to products needing development, maintenance, feedback analysis, and shifting priorities after launch. We agree working capacity for a defined period and plan work around shared priorities.

Capacity and prioritization are defined in this model, but completing every request simultaneously is not guaranteed. The most important work is selected and delivered in each period.

Standalone discovery and project-definition phase

Suited to an idea or problem whose users, processes, features, or first-version scope are not yet clear enough for an accurate estimate. The outcome can support a decision on further design and development.

Completing this phase does not oblige you to proceed with development. Its output should help you make informed decisions about the next steps, budget, and priorities.

Before implementation begins

The main terms are documented before the project starts.

Every project is different, but the proposal or contract should clarify at least the main expectations of both parties. Only the signed document constitutes the final legal text; this page is a general explanation of our process.

What are we building?

We document what's included, what's excluded, and what you'll receive at each stage.

When will we deliver?

We define estimated stage timelines and the information or approvals needed to proceed.

How do pricing and payments work?

We record the price, payment dates, and scope-change terms in the proposal or contract.

What happens after handover?

We agree on access, training, bug fixes, and the scope of support and maintenance.

Choosing how to work together

Tell us about your project so we can explore the right engagement model for its actual needs.

You don't need every detail ready to begin. Send a short description of the goal, users, current situation, and key constraints. After an initial review, we'll determine whether the project is ready for an estimate or would benefit from a discovery and definition phase first.

Describe your project and request a consultation → Explore AritaWeb services