How to Work With a Developer: Communication, Meetings and Expectations

Knowing how to work with a developer comes down to three agreements: a fixed rhythm for updates and demos, feedback they can act on, and one person on your side who makes decisions quickly. Projects rarely stall because of the code. They stall because questions sit unanswered, priorities shift every week and nobody said their expectations out loud.

I'm a freelance developer based in Denmark, so this is written from the developer's side of the table. The advice applies to freelancers, agencies and in-house developers alike, and none of it requires you to be technical.

The short answer: a working rhythm that keeps things moving

Most friction disappears once both sides know when they'll hear from each other and where things live. This is the rhythm I'd recommend for a typical project with a freelancer or a small team.

If you're still choosing who to hire, start with my step-by-step guide to hiring a developer. The rest of this post assumes the contract is signed and the work is about to start.

What a developer needs from you, and what you should get back

A working relationship has two sides, and a large share of a project's pace depends on the client.

What your developer needs from you:

• Priorities. A ranked list of what matters most, so nobody has to guess.
• Fast decisions. A good answer in two days usually beats a perfect answer in two weeks.
• Access to knowledge. Whoever knows the workflows and the odd edge cases has to be reachable.
• Access and materials on time. Logins, test data, copy and images. My freelance developer onboarding checklist lists ten things to have ready on day one.
• Testing. You're the only one who can say whether the software fits your business.

What you should expect from a good developer:

• Replies within an agreed time. Mine is one business day, and that's a fair bar for most developers.
• Updates you can follow without a technical background, and software you can actually try.
• Bad news early. "This will take longer than planned" is far more useful in week two than in week eight.
• Questions when something is unclear, instead of guesses.

Five things to agree on at kickoff

Going through these takes an hour or two at the start and saves many more hours later.

1. Name one decision-maker

Pick one person on your side with the final say on priorities and features. It doesn't have to be the CEO, but it has to be someone who is allowed to decide and has time to do it.

Several stakeholders are fine, as long as their input goes through the decision-maker. The most expensive pattern I know is sales, management and support each messaging the developer directly, which ends in mediation or in work that gets reversed a week later.

2. Decide what goes where

Agree up front where each kind of communication belongs, so messages don't get lost:

• The task list: every task, bug and request. Trello, Notion, Jira or GitHub Issues all work. What matters is that there's only one.
• Messages by email, Slack or Teams: quick clarifications and questions.
• Video calls: demos and decisions that need a real conversation.
• Phone: only when something is down or genuinely urgent.

My rule of thumb: if it's not in the task list, it doesn't exist. A request mentioned in passing on a call gets forgotten, and nobody can point to it later.

3. Set a weekly rhythm

The cadence in the table above can be dialed up or down, but it should be fixed. If I had to suggest one weekly rhythm for a typical freelance project, it would look like this:

1. Start of the week: a short written plan of what's being worked on and which questions need answers to make it happen.
2. During the week: questions go in writing to the agreed channel, and new work lands on a staging site. That's a copy of the system where you can test without affecting real users.
3. End of the week: a three-point update covering what's done, what's next and what's waiting on you.
4. Every week or two: a 30-minute demo where you see the new work in real software and agree on priorities for the next round.

Notice how few meetings that is. With a single developer, daily stand-ups are rarely needed, and every meeting eats into the time you're paying for.

4. Define "done"

To a developer, "done" might mean the code is written. To you it means the feature works for your users. That gap causes a lot of disappointment.

Agree on a shared definition, for example that a task is done only when it's tested, deployed to staging and approved by you. For larger tasks, write down in plain language what has to be true: "A customer can see their orders from the last two years and download an invoice as a PDF."

5. Agree how changes are handled

New ideas along the way are a healthy sign, but agree in advance what happens to them. On a fixed price, a new feature either replaces something else or gets its own price before work starts. On an hourly contract, agree on a monthly cap and a running breakdown of where the hours went.

How to give feedback a developer can act on

Feedback is where many projects lose the most time. "It doesn't work" takes several rounds of questions before anyone can start, while a good bug report can often be fixed right away.

A useful bug report answers five questions:

1. Where were you? The page address or the name of the screen.
2. What did you do? The steps, so the developer can repeat them.
3. What did you expect to happen?
4. What happened instead?
5. Which device and browser were you using?

Three habits do the rest:

• Describe the problem, not the fix. "Customers miss the checkout button" lets the developer propose the best solution. "Make the button red" might not solve anything.
• Separate bugs from changes. A bug is something that doesn't work as agreed. A change works as agreed, but you'd like it to work differently. Those are two different conversations, including about money.
• Batch your feedback. Ten emails in a day cost more time than one combined list, because the developer has to switch focus every time.

If you're not technical, it's completely fine to say "I don't understand what that means." A good developer can explain what a choice means for time, cost and risk without jargon. I've written more about that in the guide to hiring a developer as a non-technical founder.

Working with a developer in another time zone

If you hire outside your own country, the rhythm matters even more. I work from Denmark on Central European Time (CET), so the overlap typically looks like this:

• UK and Ireland: one hour behind. In practice, the same working day.
• Most of the EU: the same time zone, or one hour either side.
• US East Coast: six hours behind. Two standard 9-to-5 days overlap by roughly two hours, your morning and the developer's afternoon.
• US West Coast: nine hours behind, with no overlap in a standard working day.

Europe and the US change their clocks on different dates, so for a few weeks in March and around the end of October the gap to the US is an hour smaller.

With little overlap, written communication carries the project:

• Updates at the end of the developer's day, so they're waiting for you when you start yours.
• Demos in the overlap window, booked as a fixed recurring slot.
• Questions that can be answered without a call, ideally with a proposed answer.
• Honest expectations. Without shared working hours, plan for a one-day turnaround, not real-time collaboration.

Decisions and new ideas: keeping the project from stalling

Projects usually stall when a decision sits waiting, or when new requests pile on without anything coming off.

Make decisions cheap

• Ask for a recommendation with every question. "Should discount codes apply to subscriptions too? I suggest no for the first release, because it needs an extra billing rule." Now you only have to say yes or no.
• Agree on a default. If you haven't replied within a couple of business days, the developer goes ahead with their proposal. Most choices can be changed later.
• Separate small decisions from big ones. Colors and copy can be changed in minutes. Choices about data, payments and user roles are expensive to undo, so that's where your attention belongs.

Trade new ideas instead of stacking them

When a new idea comes up, you have three honest options:

• Swap: the new feature replaces something planned, and the budget holds.
• Defer: the idea goes on the list for after launch.
• Price it: it's added with its own cost and timeline, which you know before work starts.

The fourth option, adding it and hoping for the best, is one of the most common reasons timelines slip. On a fixed-price project, a swap is usually the best route. Why a fixed frame with flexible execution tends to beat a locked plan is covered in agile vs waterfall for smaller projects.

When the collaboration starts to creak

Even good working relationships go through slow patches. What matters is noticing early, and these are the signs I'd act on:

• Demos get postponed twice in a row.
• Updates turn vague: "working on it" instead of what was actually done.
• The same task has been "almost done" for weeks.
• You only hear from the developer when you reach out first.
• Bugs you reported come back after being fixed.

The signs apply to your side too. If you reply slowly or change priorities every week, even a strong developer will struggle to keep the pace.

Raise it straight away and be specific: "The last two demos were canceled. What would it take to get back on track?" The cause is often fixable, like too many tasks at once or a technical surprise nobody mentioned.

If that doesn't help, you'll be glad the code and accounts are in your name. With me, clients own the code from day one, and that should be standard. It means another developer can take over, and my guide on switching developers mid-project covers how to do it with as little loss as possible.

When a solo freelancer isn't the right setup

Working with one freelancer doesn't suit every company. It's rarely the right call if:

• You need the developer on site several days a week.
• You want daily stand-ups and regular attendance at internal meetings.
• The system needs round-the-clock cover, including when the developer is ill or on holiday.
• The work needs several specialists at once, such as design, mobile apps, data and infrastructure.

In those cases, an agency or an in-house hire is usually a better fit. What you get with a freelancer instead is a direct line to the person writing the code.

Next steps: agree on the ground rules before kickoff

Bring this checklist to your kickoff call. Agreeing on these points takes about an hour and saves a lot of misunderstandings later.

To see the kinds of projects I take on, from websites to custom web apps and SaaS, have a look at my development services.

Frequently asked questions

Should I use email or Slack with a freelance developer?+

Either works, as long as you use the same channel every time. Email is fine for most projects, and a shared Slack or Teams channel is handy when there are lots of small clarifications. Avoid splitting the conversation across email, texts, chat and phone, because decisions become impossible to find later. Tasks and bugs belong in the task list regardless of which channel you pick.

How quickly should a developer reply?+

Within one business day is a fair expectation for normal questions, and it's what I commit to myself. Developers do their best work in long stretches without interruptions, so replies within minutes are rarely realistic, and not something you should want. Urgent bugs are different. If your system is business-critical, agree on a separate response time, for example in a maintenance agreement.

Do I need daily stand-ups with a freelancer?+

Rarely. Daily stand-ups help teams coordinate work between several people, and with a single developer they mostly take time away from the actual work. A weekly written update and a demo every week or two are usually enough. During intense periods, such as the week before a launch, a short daily check-in can make sense.

What if I don't understand what my developer is telling me?+

Say so, and ask them to explain it as consequences rather than technology. Ask what the choice means for cost, time and risk, and what happens if you pick the alternative. A good developer can explain that without jargon. If a developer repeatedly can't, treat it as an early sign that communication will become a problem later in the project.

How do I keep track of hours on an hourly contract?+

Ask for a short weekly time report broken down by task, not just a total. Agree on a monthly cap and ask the developer to warn you before it's reached, so the invoice never comes as a surprise. If one task keeps eating more hours than expected, raise it at the next demo and decide together whether to continue, simplify or drop it.