“Can you just build this real quick?”
If you are good with technology, AI tools, programming, automation, or personal development projects, you have probably heard this kind of request before.
At first, it sounds casual.
Maybe the request is something like:
- I want to load a CSV file.
- I want to search by title or keyword.
- I want to copy the result with one click.
- I found this GitHub project. Can you modify it a bit?
- I want it to work with Japanese text too.
From the requester’s perspective, it may feel like a small convenience tool.
But from the builder’s perspective, it is not small.
It can involve research, requirements definition, UI design, implementation, debugging, bug checking, testing, endless revisions, and future maintenance.
That is no longer a quick favor.
That is a small software project.
And when you refuse, you may be called cold.
But is the person refusing really the cold one?
Or is it colder to ask for someone’s time, focus, limited AI tool usage, and future maintenance responsibility without doing any work yourself?
“It’s Just CSV Search, Right?” Not Really.
Let’s say someone wants a tool to save and search prompts in a CSV file.
From the user’s point of view, the desired behavior sounds simple:
- Load a CSV file.
- Search by title.
- Search by keyword.
- Click a result to copy the prompt.
- Add new rows if needed.
That sounds easy.
But the person building it has to think about many hidden details:
- What columns should the CSV have?
- Do we need an ID column?
- Should the columns be title, positive, and negative?
- Should we modify an existing tool or build a new one?
- Will Japanese text get corrupted?
- Will the CSV still work when opened in Excel?
- What happens when a prompt contains commas?
- What happens when a prompt contains line breaks?
- Do we need editing?
- Do we need deletion?
- How do we prevent the original data from being destroyed?
- How do we avoid duplicate IDs?
- Should search target only titles, or also prompt text?
- Should copy buttons copy positive, negative, or both?
- How should errors be displayed?
- What happens when the underlying tool updates and breaks compatibility?
After seeing all that, can we still call it “just CSV search”?
Not really.
It is a small but fragile management tool.
The Heavy Parts Are Requirements Definition and Bug Checking
The hardest part of a technical favor is often not writing code.
The heavy parts are requirements definition and bug checking.
If the requester clearly explains what they want, how they will use it, and what scope they expect, the work becomes much easier.
But often, many things are left undefined:
- What is the actual purpose?
- Who will use it?
- Where will it be used?
- How often will it be used?
- Will the CSV be edited manually, or inside the tool?
- Is saving enough, or is editing required?
- Is deletion required?
- What exactly should be copied?
- Should search target only titles, or also the prompt body?
- Should we modify an existing tool or build a new one?
- Who fixes it if it breaks?
- Who handles future feature requests?
If these are not shared, the builder has to infer everything.
That means the builder has to turn the requester’s vague desire into requirements, predict bugs, define edge cases, and design the tool safely.
That is real work.
Requirements definition is not just “writing down what someone wants.”
It means deciding:
- the purpose
- the usage flow
- the inputs
- the outputs
- the edge cases
- the failure behavior
- what is included
- what is not included
Bug checking is also not just pressing a button and seeing if it works.
You have to ask:
- Does it break with Japanese text?
- Does it break with commas?
- Does it break with line breaks?
- Does it break with empty fields?
- Does it break with duplicate IDs?
- Does it break when the file does not exist?
- Does a failed save destroy the original data?
- Does it overwrite existing data by accident?
- Does it break in a different environment?
- What happens after an update?
When the requester does not explain how they will use the tool, the builder has to carry all of these assumptions.
That is heavy.
The work is not just writing code.
The work is filling in everything that was left undefined.
Endless Revision Loops Are the Real Trap
Another major cost is the revision loop.
At first, people say:
“Minimum functionality is enough.”
“Just something simple is fine.”
“As long as it works, I’m happy.”
But once they see something working, new requests often appear:
- Actually, I want this changed too.
- Actually, I want the display to look different.
- Actually, I also need editing.
- Actually, I also need deletion.
- Actually, I want more search options.
- Actually, I want multiple CSV files.
- Actually, I want better Japanese sorting.
- Actually, can you make the UI easier?
These requests are not always malicious.
Sometimes people only realize what they want after they see a working version.
But for the person doing unpaid work, this is exhausting.
The reason is simple: the scope was never defined.
If the scope is not defined, it can expand forever.
“Can you also do this?”
“Can you just fix this part?”
“It broke.”
“Can you look at the thing you made before?”
This becomes an unpaid revision loop.
And revision loops cost more than time.
They cost mental switching.
You may be working on your own project, then suddenly you have to remember how your friend’s tool works.
You may want to use your own AI coding tool limit for your own app, but now you are using it for someone else’s personal tool.
You may be trying to build your own assets, but someone else’s maintenance request keeps interrupting you.
That is a real cost.
The Hardest Part Is Not Building It. It Is That It Never Ends.
The scary part of tech favors is not always the first task.
The real problem is what happens afterward.
At first, people say:
“Just something simple is fine.”
“Minimum functionality is enough.”
“As long as it works, it’s okay.”
But then it often turns into:
- It throws an error.
- It does not work.
- Japanese text is broken.
- It cannot save.
- Actually, I also want editing.
- Actually, I also want deletion.
- Actually, I want sorting by title.
- Actually, I want multiple CSV files.
- It broke after an update.
- Can you fix the thing you made before?
Once you touch the project, you may become the person responsible for it.
That is the real cost.
Not just building it once, but being linked to it whenever it breaks.
This is not just a friendly favor anymore.
It is the entrance to free maintenance.
“Cold” Is a Personal Attack That Moves the Goalpost
When you refuse, someone may call you cold.
But that word can be dangerous.
“Cold” shifts the discussion from workload to personality.
The real questions are:
- Who does the research?
- Who defines the requirements?
- Who designs it?
- Who implements it?
- Who debugs it?
- Who checks for bugs?
- Who stops the revision loop?
- Who maintains it?
- Whose time and tool limits are being used?
But once the word “cold” enters the conversation, the topic changes to:
- Are you kind?
- Are you cold?
- Are you a good friend?
- Are you selfish?
That is not the real issue.
The issue is not personality.
The issue is unpaid scope and responsibility.
Saying no to a technical request does not make someone cold.
It means they are setting a boundary around work, time, and responsibility.
If You Say “Codex Is Expensive,” Don’t Ask to Use Someone Else’s Codex for Free
AI coding tools and coding assistants often have costs and usage limits.
If someone says:
“Codex is expensive.”
“You should reconsider paying for it.”
“I only need it for this one thing, so I don’t want to subscribe.”
That is their choice.
But if they then ask someone else to build the tool for them, that changes the situation.
They do not want to pay.
They do not want to subscribe.
They do not want to research.
But they want to use someone else’s Codex limit, time, and attention.
That is not fair.
The other person’s AI tool usage limit exists for their own projects, apps, work, and learning.
Using that limited capacity for a highly personalized tool for someone else is not free.
It consumes time, attention, and opportunity.
If you think a tool is too expensive for yourself, you should not casually ask someone else to spend their paid tool usage on you for free.
Refusing Is Not Cold. Ignoring the Other Person’s Workload Is.
The person being refused may feel that you are cold.
But let’s look at the situation.
They do not research.
They do not pay for the tools.
They do not define the requirements.
They do not explain how they will use it.
They do not implement it.
They do not debug it.
But they expect someone else to research, define, design, build, fix, and maintain it.
Then, when the other person refuses, they call them cold.
Is that really fair?
If you are truly friends, you should be able to imagine the other person’s workload.
Your tech-savvy friend also has their own projects.
Their own apps.
Their own work.
Their own learning.
Their own limited AI tool usage.
Their own future assets to build.
Asking for help does not only consume “a little time.”
It consumes attention, decision-making, tool limits, and future asset-building time.
Ignoring that cost and calling the refusal cold may actually be the colder behavior.
“I Tried and Got Stuck” Is Different From “Do Everything for Me”
The difference is in the way the request is made.
This kind of request is reasonable:
“I tried setting it up.”
“I followed this GitHub instruction.”
“This error appeared.”
“I do not understand this one part.”
“I tried these things.”
“Can you look at this one issue?”
That is easy to help with.
But this kind of request is heavy:
“Figure out what I need.”
“Read the GitHub project for me.”
“Define the requirements.”
“Guess how I will use it.”
“Check the bugs in advance.”
“Make it work.”
“Fix it when it breaks.”
“Handle future changes.”
“But do it for free.”
That is not a simple question.
That is outsourcing.
These two should not be treated as the same thing.
A Tech-Savvy Friend’s Time Is Not Free
Tech-savvy people often make answers look easy.
That can create a misunderstanding.
People may think:
“You know this stuff, right?”
“It should be easy for you.”
“You can just use AI.”
But speed comes from experience.
The person is using skills such as:
- breaking down vague problems
- defining requirements
- predicting bugs
- reading existing code
- understanding tool limitations
- preventing data loss
- imagining user behavior
- estimating future maintenance
- detecting likely revision loops
All of that is work.
It costs time and focus.
For an indie developer, that time could have been used for their own app, article, product, monetization, or learning.
Using someone’s time means taking away time they could have invested in their own future assets.
Friendship Does Not Mean Unlimited Free Work
Helping a friend is fine.
Giving advice is fine.
Looking at one specific error is fine.
Teaching someone how to research is fine.
Pointing them in the right direction is fine.
But friendship does not mean unlimited free labor.
In fact, if you are really friends, you should try to imagine the other person’s workload first.
Before asking for technical help, prepare at least:
1. What you want to do
2. How you plan to use it
3. What you already tried
4. Where you got stuck
5. The error message or screenshot
6. What you tried to fix it
7. The one specific point you want help with
8. Whether you are willing to pay if the work is large
Without this, the other person has to organize your vague desire for you.
That is no longer a friendly question.
That is free requirements definition.
Summary: If You Are Friends, Imagine the Other Person’s Cost
Helping friends is good.
But asking friends to do unlimited free technical work is different.
A “small favor” can include research, requirements definition, implementation, debugging, bug checking, endless revisions, and ongoing maintenance.
The heaviest parts are often requirements definition and bug checking.
If you do not explain how you will use the tool, the other person has to fill in all the undefined parts.
And after it is built, it can easily become an endless loop of:
“Actually, change this.”
“It broke.”
“Can you fix the thing you made before?”
That is why boundaries matter.
If someone tried and got stuck on one specific issue, help may be reasonable.
But if they do nothing and ask someone else to do everything, that is free outsourcing.
Refusing is not cold.
Ignoring someone else’s workload, tool limits, time, and future maintenance burden may be the colder behavior.
If you are friends, imagine the cost before asking.
