# Sales Promised Friday Because Claude Builds It in an Hour

> The agent made the code almost free. The estimate was never about the code. Count the decisions only people can make, and give options with dates.

- URL: https://hsalem.com/claude-builds-it-in-an-hour/
- Author: Hassan Salem (https://hsalem.com/about/)
- Published: 2026-11-05
- Topics: Communication, AI, Management, Software Engineering

"Small question. How long would a CSV import take? The customer asked, and I said Friday. Claude can build it in an hour, right?"

Tuesday, 16:05. Jonas from sales, in a direct message. Before I could answer, a second message: "They want to move their 4,000 contacts from the old tool. Demo call is Friday 10:00."

Jonas joined us two months ago. He is good with customers, really good. And like everybody in our company, he uses AI every day. He writes his emails with it, he builds his pitch decks with it, and last week he made a small internal dashboard with it over lunch. So for him "a feature" is something you describe in a chat, and twenty minutes later it exists.

I wrote "let me check". He wrote back a thumbs up and "you're the best".

## Forty minutes

Here is the uncomfortable part. Jonas was not completely wrong.

I opened a session with the agent, pointed it at our contacts module and wrote a short prompt. Upload a CSV, map the columns to our fields, create the contacts. It read the code, found our `ContactService`, and wrote an endpoint, a parser, a small mapping screen and some tests. Forty minutes, and most of that time I was reading.

I tried it with a file I made myself. Ten rows, clean headers, all good. The contacts appeared in the list. Honestly, it looked like a feature.

For a moment I thought about writing Jonas "done, Friday is fine". It would have felt very nice.

Then I did what I always do before I believe anything. I asked Jonas for a real file from the customer.

## The real file

He sent it in five minutes. `kontakte_export_final2.csv`. 4,212 rows.

I ran the import. The response came back fast and green:

```json
{ "imported": 3688, "status": "OK" }
```

3,688 of 4,212. Green. OK. And no word about the other 524.

I looked at the file. It came from an old desktop tool, so it was separated by semicolons, not commas, and it was not UTF-8. Every "Müller" became "M�ller". Phone numbers had spaces and slashes. Some rows had the same email twice, because in the old tool one person could exist once per office. And the agent's code, which was very clean and very readable, did this:

```kotlin
rows.mapNotNull { row ->
    runCatching { mapper.toContact(row) }.getOrNull()
}.forEach(contactService::create)
```

Every row that failed was just dropped. No log, no report. The customer would import their contacts, see a nice number, and find out two weeks later that a tenth of their clients are missing.

I was frustrated, I admit. Not because the code was bad. Because it was good in exactly the way that hides problems. The agent built what I described. I described a happy path, so I got a beautiful happy path.

And I knew the real problem was not the code. It was Friday.

> The agent made the typing almost free. It did nothing for the deciding, and the deciding was the whole estimate.

## Asking the agent for questions, not code

So I stopped asking for code. I wrote a different prompt:

```
Do not write code.
We will import 4,000 contacts from this real file for a paying customer.
List every decision a human must make before this is safe to ship.
For each one: what goes wrong if we decide nothing,
and who should decide it (engineering, product, or the customer).
```

This is where the agent was really good. Better than me alone, I think, at least on speed. It came back with seventeen points. Some I had already seen. Some I had not thought about yet:

1. Encoding and separator: detect them, or ask the user?
2. Duplicate emails: merge, skip, or create two contacts?
3. What happens if the customer imports the same file twice?
4. Do imported contacts trigger our welcome email automation? (They did. 4,000 welcome emails to people who never signed up for anything.)
5. Is it all or nothing, or can 200 rows fail and the rest go in?
6. Who sees the failed rows, and how do they fix them?

Number four made my stomach drop a little. Nobody would have caught that in a demo.

Then I sorted the list into two piles. Things I can decide alone, and things only the customer or Jonas can decide. The second pile had six points. Six questions is not a technical problem. It is a phone call.

## Talking to Jonas

I called him instead of writing. Writing "it's more complicated" in Slack makes engineers sound like they are protecting their time. On a call you can show the file.

I shared my screen and showed him the response. 3,688 imported, status OK. Then I showed him the 524 rows that disappeared, with real names of real people from his customer.

He was quiet for a moment. Then: "But it says OK."

"Yes. That's the problem."

Then I showed him the welcome email point. He laughed, the nervous kind of laugh. "Okay. That would have been a very bad Friday."

I did not give him a number of days. I gave him two options.

**Option one, Friday:** the import works for this one customer's file. It shows a preview of the first twenty rows before anything is saved. Every failed row lands in a downloadable error file with the reason. No automations. If they import twice, duplicates are skipped by email.

**Option two, the week after:** a general import for any file, with column mapping, merge rules and an undo.

And I gave him the six questions for the customer, written in normal language, not in my language. "If one person works in two of your offices, should they be one contact or two?"

Jonas took option one and the questions to the customer on Wednesday morning. The customer answered all six in one email. Two answers surprised me. They wanted duplicates merged, not skipped, and they did not care about the old notes field at all. So one decision got harder and one problem disappeared completely.

## Friday, 10:00

The agent wrote most of option one on Wednesday and Thursday. I split the work in small steps: first the encoding detection with tests built from the real file, then the error report, then the preview. After each step I read the diff, and I ran the real file again. The idea was simple. The real file is the test. If the number of imported rows plus the number of error rows is not 4,212, something is lying.

It was not all smooth. On Thursday the agent "improved" the duplicate merge by keeping the newest row, and the newest row in the old tool was often the one with an empty phone number. I caught it because the error report suddenly had fewer rows than the day before, and fewer is not always better. We changed it to merge field by field, and keep non-empty values.

Friday at 10:00 Jonas did the demo. 4,094 contacts imported, 118 rows in the error file, each with a reason like "email missing" or "phone number not readable". The customer's office manager opened the error file during the call and said: "Oh, these are the ones Klaus never finished." She knew exactly who Klaus was. We did not.

Option two is still in progress. The general mapping screen is harder than it looked, and I am not sure yet how much of it we really need.

## What I do now when someone says "AI can build it in an hour"

1. **Run the real data before you answer.** The agent's first version will usually work on your clean test file. Ask for the customer's ugliest real file on day one, and make it part of the tests.
2. **Ask the agent for decisions, not code.** "List every decision a human must make before this is safe" gives you the real size of the work in ten minutes. Then count the questions only other people can answer. That number is your estimate risk.
3. **Never let a summary say OK when rows are missing.** Imported plus failed must equal the total. Put this check into the code and into your review habit.
4. **Give options with dates, not one number.** "Friday for this file, next week for every file" is something a sales person can sell. "It's complicated" is not.
5. **Translate the questions for the customer.** Six clear questions in their words got answers in one email. The same questions in my words would have needed a meeting.

The funny part: Jonas was right about the hour. The code really took about an hour. The other three days were questions, and only people could answer them.

How do you estimate work now, when everybody around you has seen code appear in a minute?