The App Was Simple. The Rules Weren’t.

My phone rings on a Tuesday afternoon. It’s Vladimir, a friend I haven’t spoken to in a few weeks. He’s a cameraman, he runs a small camera crew at a TV station, and he calls me when he has a technical problem he thinks I can solve.

“Dejan, listen. I need a simple application. A shift schedule. Nothing complicated. A table, a few workers, who works when. Can you make that for me?”

I say sure, tell me what you need.

Ninety minutes later, I’m still on the phone, and we have not finished.

This post is about what happened in those ninety minutes, and the one thing I should have done at the start that would have saved me half of them. If you’ve ever had a stakeholder, a client, or a friend describe a “simple” project to you, this story is going to feel familiar. And the lesson at the end is the one I wish I’d learned five years earlier than I did.

The opening

Vladimir starts by laying out the problem. There are 27 people on his team. The boss wants the schedule to be fair. Right now, everyone wants the second shift because it suits them better. But if everyone is in the second shift, who works the first one? Nobody.

“So I thought,” Vladimir says, “the modest ones should get preference. Whoever asks for the second shift only when they really need it, not every day. The greedy ones who want it every day, they should not have priority.”

I’m taking notes. So far, so reasonable. I ask my first real question.

How many people must be in the first shift for it to function?

He pauses. “Eleven, minimum. We can do it with fewer in an emergency, but eleven is the working minimum.”

And the maximum in the second shift?

“Four. Sometimes I let it go to five if there’s a special reason, but four is the rule.”

I write down: 11 minimum, 4 maximum. And I think to myself, okay, this is straightforward. Two numbers, one rule. We can be done in twenty minutes.

We are not done in twenty minutes.

The questions that don’t end

The trouble starts when I ask what happens when more than four people want the second shift. Because the way Vladimir originally framed it, modest people get priority. But what does modest actually mean? How many days of second shift in a week makes someone modest, and how many makes them greedy?

Vladimir thinks about it. “One or two days, that’s modest. Three or more, that’s greed.”

Okay. New question. What if two modest workers want the same day, and there’s only one spot left? Who wins?

“Whoever asked first.”

What if a modest worker asks for a day where the four spots are already filled with greedy workers?

“Then the modest one bumps a greedy one.”

Which greedy one?

A longer pause this time. “I don’t know. The first one we put in, I guess.”

And the bumped worker, do we tell them?

“I don’t know.”

This goes on for a while. We get to the weekend, and it turns out the weekend doesn’t work like the weekdays at all. Workers rank two preferences instead of picking one. We get to the input window, and it turns out the schedule for next week can only be filled out on Friday between 8 AM and noon. We get to holidays, and we discover that nobody has thought about what happens when Friday is a holiday.

By the end of the call, I have four pages of notes. Vladimir, who started the conversation thinking this was a two-day project he would casually pay for out of pocket, has gone quiet. At one point he says, “I didn’t realize there was this much in it.”

There is always this much in it. The problem is, you can’t see it until you start asking the right questions.

What I did wrong

After we hung up, I started writing the functional requirement document. Not the code, not the database schema, not the screen mockups. The plain-language description of what the application is supposed to do.

A week later, I went back to Vladimir with a second round of questions. The first round had answered the obvious ones. The second round was about everything that only became visible once I tried to write the answers down. The displacement mechanism, the partial submissions, the holiday case. None of these things came up in the first ninety minutes because we didn’t know to ask.

The app wasn’t complicated. The rules were.

I want to stop here and tell you something honest. I did this the way I’ve always done it. Pen, paper, listen carefully, ask follow-up questions, write up notes, come back for round two. It’s how I was taught. It’s how most analysts and product owners I know still do it.

There was a faster way available to me, and I didn’t use it. I want to show it to you, because I think it’s the single highest-leverage move you can make in any conversation like the one I just described.

The move I should have made

Here’s what I would do differently if Vladimir called me again tomorrow.

I would let him talk. I would not try to organize his thoughts in real time, and I would not try to translate his words into clean requirements as he speaks. I would just listen, and I would write down what he says as close to verbatim as I can manage. Tangents and all.

When the call ends, I would open an AI tool. I would paste Vladimir’s words inside quotation marks, exactly as he said them, with no cleanup. And underneath the quote, I would add this single instruction:

Do not assume anything beyond what is stated. Ask clarifying questions if the request is ambiguous.

That’s it. The whole move.

Here’s what that looks like in practice. The raw input I would have pasted, working from my notes:

“There are 27 of us. Everyone wants the second shift because it suits them better. But if everyone is in the second shift, who works the first one? Nobody. So the modest ones should get preference, the ones who only ask when they really need it. The greedy ones who want it every day should not have priority. The weekend is something else, that has its own rules. And it has to be every Friday from eight to twelve, because that’s when we know the schedule for next week.”

Two hundred words. Vladimir’s actual phrasing, no cleanup. When I run this through an AI tool with the instruction line underneath, here’s the kind of response that comes back:

• How many workers must be in the first shift for the system to function?
• What is the maximum number of workers allowed in the second shift?
• When you say “modest” and “greedy,” how many days of second shift defines each?
• If two modest workers request the same day, who gets priority?
• What happens to a worker whose spot is taken away by a higher-priority request?
• Are they notified, automatically reassigned, or left for the administrator to handle?
• Does the weekend follow the same rules as the weekdays, or different ones?
• What happens if Friday falls on a holiday?

Every single one of those questions came up during my actual ninety-minute call with Vladimir. Some of them came up in round two, a week later. The AI surfaced all of them in about thirty seconds, working from his unedited words.

Now, this isn’t magic, and it doesn’t always work cleanly. Sometimes the AI hallucinates a constraint that wasn’t there. Sometimes it invents a rule the stakeholder never mentioned and presents it as if it came from the request. The instruction line is there for exactly that reason. Telling the AI not to assume anything beyond what is stated cuts down most of the inventing. Not all of it. You still read the questions and discard the ones that don’t fit. But that’s a faster job than generating the questions yourself.

What was actually at stake

The lesson here isn’t really about saving an hour. It’s about what happens when you don’t ask those questions.

If Vladimir and I had ended the call at the twenty-minute mark, both of us thinking we understood the system, we would have walked away with the same words and two completely different applications in our heads. He would have expected one thing, I would have built another, and the gap would have surfaced sometime around the first week of testing. Probably later. Probably in front of his boss.

That’s the real cost of skipping the questions. Not slow development. Misaligned development. Two people agreeing on a sentence and disagreeing on what it means, without either of them noticing for weeks.

The faster you surface those disagreements, the cheaper they are to fix. That’s the whole game.

What you can do this week

Find a stakeholder message in your inbox or your notes. The messier, the better. A Slack thread, a meeting transcript, an email that wanders from a feature request into a complaint into a vague directive. Paste it into your AI tool of choice, inside quotation marks. Add the instruction line above. See what comes back.

If you’ve never done this before, the first time you try it is going to feel a little bit like the moment I described above. The questions you’ve been generating one by one, slowly, with your professional intuition, start arriving in a list. Not because the AI is smarter than you. Because it’s faster, and because it isn’t trying to be polite while the stakeholder waits on the line.

The rest of the framework

Raw Request Capture is one of five steps I now use to take a vague stakeholder request and turn it into a sprint-ready user story, with acceptance criteria, edge cases, and a quality check, in under ten minutes.

The other four steps are how you turn the AI’s clarifying questions into structure. How you stop it from hallucinating features that don’t exist in your product. How you force it to surface edge cases you’d never think of on your own. And how you validate the final story against the INVEST criteria so it doesn’t get rejected in Sprint Planning.

I’ve packaged the whole framework into a course called The AI-Powered Backlog Refiner. It launches soon, and if you want early access plus a discount when it goes live, you can join the waitlist here:

Join the waitlist for The AI-Powered Backlog Refiner

That’s the funny thing about software. The application is almost never the hard part. The hard part is pulling the rules out of people’s heads before they build the thing themselves, in the wrong direction, for two weeks.

Vladimir, by the way, is fine. The spec is finished, the application is in development, and last time we spoke he told me two coworkers have asked if they can use it for their own crews.

He still calls it a simple app.

I let him say it.

The App Was Simple. The Rules Weren’t.

Dejan Majkić