How I Work With Clients: From First Message to Production Handover

Hiring a developer is about more than finding someone who can write code. You need to explain what you want to build, understand what the work involves, make decisions at the right time, and know what happens when the application is ready to launch.

My approach is to make that process clear from the beginning. We start by understanding the problem, define the work before committing to it, build in manageable stages, review what is being delivered, and plan the handover rather than leaving it until the last day.

Every project is different, so the exact steps depend on its size, complexity, and existing setup. A small website update does not need the same process as a custom web application with multiple integrations. The goal is to use enough structure to keep the work understandable without creating unnecessary process.

Here is what working with me can look like, from the first message to production handover.

1. You Send the First Message

The process begins when you get in touch and share what you are trying to build or improve.

You do not need a complete technical specification to start the conversation. A short explanation of the business problem, the users involved, and what you hope to achieve is a useful starting point.

If you already have a brief, wireframes, screenshots, an existing website, or a list of requirements, you can share those too. If your idea is still taking shape, we can begin by clarifying the problem and identifying what needs to be decided.

Helpful details to include are:

• What you want to build or change.
• Who will use it and what they need to do.
• Whether an existing website, application, or codebase is involved.
• Any important deadline or external dependency.
• Your approximate budget range, if you have one.
• What you would consider a successful outcome.

The first message is not about knowing every technical detail. It is about giving us enough context to decide what conversation should happen next.

2. We Check Whether the Project Is a Good Fit

Not every project should move straight into development. Before estimating the work, I need to understand whether the requested outcome is realistic for the available scope, timeline, and resources.

We discuss the problem you are solving, the users and workflows involved, what already exists, and the constraints that may affect the solution. That might include a third-party API, an existing database, a required technology, or a launch date that depends on another team.

This is also the point to identify unanswered questions. Sometimes the right next step is a focused discovery phase; sometimes the requirements are already clear enough to estimate. If a request is outside my experience or the available constraints make the intended outcome unrealistic, it is better to discuss that early rather than discover it after work has started.

The purpose of this conversation is mutual clarity. You should have a better understanding of the technical work, and I should have a better understanding of what the business actually needs.

3. We Define the Scope and Requirements

Once the project looks like a fit, the next step is to turn the idea into a scope that can be discussed, estimated, and reviewed.

A useful scope explains what will be delivered—not just the broad category of work. For a web application, that could mean identifying user roles, key screens, important workflows, integrations, and the data the system needs to handle.

We also clarify what is not included. For example, a first release might include account registration and a user dashboard but exclude a mobile application, a complex reporting module, or integrations that have not yet been specified.

The exact documentation depends on the project, but we aim to clarify:

• The main goals and intended users.
• The features and workflows included in the work.
• Relevant technical constraints and integrations.
• Deliverables and how they will be reviewed.
• Assumptions, dependencies, and exclusions.
• Known risks and unanswered questions.
• What would count as an acceptable result.

If the project is still too uncertain to estimate responsibly, it may make sense to define and price a discovery phase first. That phase can reduce uncertainty before committing to a larger build.

If you are preparing your requirements, the web project brief template can help you organise the information before we discuss the details.

4. We Agree on Deliverables, Timeline, and Commercial Terms

With the scope understood, we can discuss how the work will be delivered and paid for.

Depending on the project, the arrangement may be based on an agreed scope, milestones, or time spent. The appropriate model depends on how clearly the requirements are defined and how much change is likely during development.

Before work begins, the important terms should be clear. These can include the deliverables, estimated timeline, payment schedule, review responsibilities, how changes will be handled, and any agreed support after launch.

A timeline is only meaningful when its assumptions are visible. Progress may depend on receiving content, credentials, feedback, design decisions, or access to third-party services. If those inputs are delayed, the plan may need to change.

I want both sides to understand what is being agreed to before development starts. That reduces the chance of different expectations about what is included, when decisions are needed, or what happens if the requirements change.

5. We Set Up the Project

Once the scope and terms are agreed, we prepare the project so that work can begin in an organised way.

The setup depends on whether we are creating something new or working with an existing application. It may involve reviewing the current codebase, confirming the technology stack, setting up version control, preparing a development environment, identifying required services, and agreeing on how progress and feedback will be shared.

Access should be handled carefully. Where possible, client-owned accounts and services should remain under the client's control, with appropriate access granted for the work. Sensitive credentials should not be casually shared in messages or stored in source code.

This stage also helps surface practical dependencies. If development requires access to an API, sample data, hosting, design files, or a decision from another stakeholder, we identify that before it becomes an unexpected blocker.

6. I Build the Application in Manageable Stages

Rather than treating the entire project as a black box until the final day, I aim to break the work into understandable features or milestones.

The specific order depends on the project. A web application might begin with its core data model and authentication, then move through the main user workflows, integrations, and administrative features. Another project may need a different sequence.

During development, the focus is on building the agreed functionality while keeping the code understandable and maintainable. That can include frontend work, backend logic, APIs, database changes, integration work, and the supporting tests.

When a milestone or review point is appropriate, you can see what has been completed and provide feedback against the agreed requirements. This gives us a chance to catch misunderstandings before they spread across the project.

Not every implementation detail needs a meeting. Clear written updates and focused review sessions are often enough, especially when the requirements and acceptance criteria are documented.

7. You Review Progress and Provide Feedback

Client feedback is part of the development process, not just a final approval step.

When a working feature is ready for review, you can check whether it supports the intended workflow and whether it matches the agreed requirements. Feedback is most useful when it is specific: what happened, what you expected, and which requirement or user need is affected.

We should also distinguish between a defect, a clarification, and a new request:

• Defect: The delivered work does not behave as agreed.
• Clarification: A requirement needs further explanation.
• Change request: You want to add or alter something beyond the agreed scope.

These categories may be handled differently depending on the agreement. A clear process helps us decide whether a change can be included, affects the timeline, or needs a separate estimate.

Timely feedback matters because development often depends on decisions. If a review is delayed, the next stage may need to wait rather than proceed on an assumption.

8. I Test the Work Before Production

A feature that works during development is not automatically ready for real users. Before release, the application needs appropriate testing based on the scope and risk of the project.

That may include checking the main user workflows, validating inputs, testing permissions, verifying database changes, checking API behavior, and confirming that integrations respond as expected. I also look for important failure cases—for example, what happens when a request is invalid or a service is temporarily unavailable.

The amount of testing varies. A small change may need a focused set of checks, while a larger application may need more extensive automated and manual testing.

Where client acceptance testing is part of the project, you may be asked to review the application in a staging or test environment using realistic scenarios. That helps confirm that the result meets the agreed requirements before it goes live.

Testing cannot guarantee that no issue will ever occur. It is a way to reduce risk, find defects before release, and make the state of the application clearer.

9. We Prepare for Production Deployment

Production deployment is the step where the application or change is released to the environment intended for real users.

The exact procedure depends on the hosting setup and application architecture. It may involve configuring environment variables, checking database migrations, preparing a release, updating DNS or service settings where relevant, and verifying that required integrations are connected.

For a project with meaningful operational risk, it is also important to understand how to recognise a failed release and what rollback or recovery options are available. Not every project needs a complex deployment pipeline, but production changes should be made deliberately.

Before or immediately after release, the critical workflows should be checked in the production environment. A successful deployment message alone does not prove that every part of the application is behaving correctly.

Where the client owns the production accounts, access and responsibilities should be agreed in advance. If I am deploying into an existing environment, the process also needs to respect the client's established security and release requirements.

10. We Complete the Production Handover

Going live is an important milestone, but it is not the same as handing over a maintainable product.

The handover should leave you with the agreed deliverables and enough information to understand how to access, operate, and maintain what has been built. The exact items depend on the project and the commercial agreement.

A handover may include:

• Source code or repository access, as agreed.
• Relevant production URLs and environment information.
• Setup and deployment instructions.
• Documentation for important features, integrations, or configuration.
• Transfer or confirmation of appropriate account access.
• Known limitations or outstanding items.
• A walkthrough of the application or key workflows, where agreed.
• A clear explanation of any included post-launch support.

Access should be verified rather than assumed. If a repository invitation or account transfer is part of the handover, the relevant client contact should confirm that they can access it.

I also want to make the next step clear: who handles future changes, how issues should be reported, and what support is included versus separately scoped. That helps avoid the assumption that every future request is automatically part of the original project.

11. What Happens After Launch?

Software needs maintenance after release. Dependencies may need updates, users may uncover issues, and the business may want new features as its needs change.

The post-launch arrangement depends on what we agreed. It may include a defined period for addressing eligible defects, a separate maintenance arrangement, or a new scope for additional features. Those terms should be clear rather than left to assumption.

If an issue appears after launch, useful information includes what you were trying to do, what happened, what you expected, and any relevant error message or screenshot that can be shared safely. This makes investigation more efficient.

New features are best handled as planned work: clarify the desired outcome, check how it affects the existing system, and agree on the scope before implementation.

The goal is to leave you with a product that has a clear path forward, whether you continue working with me or another developer takes over later.

What I Need From You to Keep the Project Moving

A successful project is a collaboration. My role is to clarify the technical work, build and test the agreed solution, communicate progress, and make the handover clear. Your role is to help us make the business decisions that development depends on.

You can help by:

• Sharing requirements, existing documentation, and relevant context early.
• Providing the access and materials needed for the work through appropriate channels.
• Identifying who can approve decisions and review deliverables.
• Giving consolidated, specific feedback within the agreed review window.
• Raising new requirements as they emerge rather than assuming they are already included.
• Reviewing and confirming the handover items when the project is complete.

You do not need to know how to implement the software. You do need to help define what it should achieve and make decisions when the project depends on them.

Ready to Discuss Your Project?

If you have an idea for a web application, need help improving an existing product, or want to understand the work involved before committing, the first step is a conversation about the problem and the outcome you need.

You do not need every technical decision figured out in advance. Share what you know, what you want to achieve, and any constraints you already have. From there, we can work out whether the project is a fit and what a sensible next step would be.

Get in touch through the contact page to tell me about your project.