How a Project Starts
Every engagement at development.city starts with a conversation.
Whether you already know exactly what you need or simply know that something isn't working as well as it should, we'll start by understanding the situation before recommending a solution.
No unnecessary complexity. No assumptions. No building before we understand the problem.
1. Initial Conversation
Everything starts with a conversation.
Tell us:
What you're trying to achieve
What's currently not working
What's slowing you down
What systems or processes you already have
What you'd like to improve
Any important constraints or requirements
You don't need to arrive with a technical specification.
You bring the problem. We'll help explore the possibilities.
Initial conversations may be free and non-binding, depending on the type of enquiry.
2. Understanding the Problem
Before deciding what to build, we need to understand what we're actually trying to solve.
We'll look at things such as:
Your goals
Your current workflow
Existing technology
People involved
Data and information flows
Integrations you may need
Security and privacy considerations
Budget and timeline
Future requirements
Sometimes this confirms that the solution you had in mind is the right one.
Sometimes we find a simpler approach.
And occasionally, we discover that you don't need to build anything at all.
That's useful information too.
3. Scoping
Once we understand the problem, we turn the conversation into a practical scope.
This defines:
What we'll do
The infrastructure, services, configuration, integrations, or other work included in the engagement.
What we won't do
Clear boundaries are just as important as deliverables.
Dependencies
Anything we need from you, your existing systems, or third-party services.
Assumptions
Important conditions that the proposed solution depends on.
Success Criteria
Where appropriate, we'll define what a successful outcome looks like so that everyone understands what we're working toward.
For more complex projects, this stage may include a paid discovery or assessment phase before the final scope is established.
4. The Proposal
Once the scope is sufficiently clear, we'll provide a written proposal where appropriate.
Depending on the engagement, this may include:
Scope and deliverables
Project boundaries
Milestones
Expected timeline
Pricing
Payment terms
Responsibilities
Dependencies
Support or maintenance arrangements
Other relevant conditions
The goal is to make the engagement understandable before the work begins.
No mysterious surprises hiding behind the curtain.
5. Agreement
If you decide to proceed, the agreed scope, commercial terms, and responsibilities are documented in the appropriate agreement.
This is the point where an idea becomes an actual engagement.
Both sides should understand:
What is being built.
Who is responsible for what.
When things are expected to happen.
How changes will be handled.
What happens after delivery.
Clear expectations make projects easier for everyone.
6. Onboarding & Kickoff
Once the engagement is confirmed, we move into onboarding.
Depending on the project, this may involve:
Providing access to relevant systems
Confirming project contacts
Sharing documentation
Providing brand assets
Confirming technical requirements
Reviewing existing infrastructure
Setting up communication channels
Confirming milestones and responsibilities
We'll provide the information you need to get started.
The exact onboarding process depends on the type and complexity of the project.
7. Building & Collaboration
Once everything is ready, the work begins.
Depending on the project, this may involve configuration, development, integration, automation, testing, documentation, training, or a combination of these.
We'll work through the agreed milestones and keep communication structured throughout the process.
You'll have opportunities to:
Review progress
Ask questions
Provide feedback
Confirm decisions
Identify changes or new requirements
The earlier something important is identified, the easier it usually is to address.
8. Changes & New Requirements
Projects sometimes evolve.
You may discover something new once you see the system in practice.
A requirement may change.
A third-party service may introduce a limitation.
Or a better idea may appear halfway through the project.
That's normal.
Where a change affects the agreed scope, timeline, cost, or dependencies, we'll explain the impact before proceeding.
No silent scope creep.
9. Delivery
When the agreed work is ready, we'll move through the appropriate review and acceptance process.
Depending on the project, delivery may include:
Final configuration
Testing
Documentation
Training
Access setup
Handover
Launch support
Confirmation of completion
The exact process depends on what has been agreed.
The objective is always the same:
Make sure you know what you're receiving and how to use it.
10. After Delivery
Delivery isn't necessarily the end of the relationship.
Depending on your agreement, we may continue providing:
Maintenance
Technical support
Monitoring
Updates
Additional development
Training
Strategic sessions
Infrastructure management
Further integrations
Some projects are one-off engagements.
Others develop into longer-term relationships.
You decide what makes sense for your organisation.
The Short Version
The development.city process is straightforward:
Talk → Understand → Scope → Propose → Agree → Onboard → Build → Review → Deliver → Support
The exact path can vary depending on the project.
But the principle remains:
Understand the problem before building the solution.
Build what was agreed.
Communicate when things change.
Deliver something useful.
Build better. Connect smarter. Scale sustainably.
#ForPeopleForPlanet