What to bring to a first meeting with a developer

You have a process that takes too long. Maybe it's an Excel file only one person understands, or a list of customers someone has to call by hand. You've decided to talk to a developer about it.

What you bring to that first meeting decides most of what happens next. It decides whether the solution fits, what it costs, and whether it's in use six months later.

Why first meetings go wrong

Most people come with a list of features: "We need a dashboard, a login, an export to Excel, and an app."

That feels like being prepared, but it skips the most useful part. Features are guesses about the solution. A developer can't judge whether they're the right guesses until they understand the problem.

The best first meetings are mostly about how your business works today. The solution often takes shape in that conversation, on paper.

Bring these five things

1. The process as it runs today, step by step. Who does what, in what order, using which tools? It doesn't need to be pretty. A list on a piece of paper is enough: "Anna exports the list on Monday. She sorts it in Excel. She sends it to the sales team. They call and write notes in their own sheets."

2. Where it breaks or takes time. Point to the exact steps that hurt. Where do mistakes happen? Where does the work wait for someone? Which step does everyone dread?

3. Real examples. Bring the actual Excel file, a real email, a screenshot of the system you use today. Real examples show things nobody remembers to mention: odd columns, special cases, the workaround someone invented three years ago.

4. Who will use it every day. Name the people and their roles. A tool for five salespeople on the phone looks very different from a tool for one office manager at a desk. If the daily users aren't in the meeting, write down how they work.

5. What "better" means to you. Pick one or two things you can measure: fewer hours per week, fewer mistakes, more orders, faster replies to customers. That gives everyone a goal and a way to check later whether it worked.

What you can leave at home

• A full feature list. Bring the problem instead. Features follow from it.
• A finished design. Sketches are welcome, but don't lock yourself in before anyone has looked at the process.
• A fixed price in your head. Bring a rough budget range if you have one. The right first step is often smaller and cheaper than people expect.

An example: a tyre hotel full of unused sales leads

Däckline is a tyre retailer in Helsingborg with a tyre hotel. Every season they measure the tread on every stored set of tyres, so their system already knew which customers needed new ones.

The information was never the problem. Acting on it was. Every one of those customers needed a phone call, a quote for their own car and a booking, and that work piled up in the busy season.

In the first meeting we didn't start with features. We spent the time on the real problem: how the process ran, where it got stuck, and who did the work. Talking it through properly is what showed us the best way to solve it. The meeting itself shaped the solution. After the meeting we sent a written offer with two ways to solve it. Däckline picked one, and work started right away.

The result was a campaign tool. Each customer gets a personal offer by text and email, showing their own car and the measured tread on each wheel, and can order with a few taps. In the first campaign, 480 customers got an offer and four in ten ordered through it. You can read the full story in our Däckline case study.

What a good developer should do in that meeting

You're also testing the developer. In a good first meeting, they will:

• Ask more than they talk, mostly about how your business works, not about technology.
• Sketch the solution with you, on paper or a whiteboard, in your words.
• Suggest a small first step, something that's useful within weeks, not a large system delivered in a year.
• Say no to things you don't need, even if it means a smaller project for them.

If you leave the meeting with a clear picture of the problem and one concrete next step, it was a good meeting.

A checklist to copy

Before your next meeting, write down:

• Our process today, step by step
• The two or three steps that take the most time or cause mistakes
• Real examples: files, emails, screenshots
• The people who will use the new tool every day
• One or two numbers that would show it worked

That's it. One page is enough.

---

We write about practical software for small and medium-sized businesses: what to automate, when to build, and how to get it right the first time. Follow ScideTech on LinkedIn to get the next post.