Saying 'No' Is Harder Than Hearing It: Lessons from a Tough Decision

PS: I might update this blog post, if I feel like context is missing or I worded something wrong.

Telling a company “no” is harder than receiving one. Just had an experience I didn’t think I’d get. After 6+ meetings and 1.5 years of talks, the contract had too many unresolved issues for me to consider working there.

A project I rewrote

While being unemployed, I worked on a project for several months that was a complete rewrite on my own time. After presenting the demo in one of the first meetings we had, the company hoped I would use that software - or parts of it - to build and finish the project.

It was a project I was passionate about, and I saw an opportunity to experiment with new workflows and concepts that could improve the end-user experience. The rewrite wasn’t something they requested but something I wanted to do because I believed it could demonstrate my skills and a better direction for the project.

Issues with the Contract

They wanted a 50% time commitment (for a work period of 3 months), which was way below fair pay for a software engineer and included a clause restricting me from using the expertise, software, or knowledge gained for future work. I wrote a blog post that addresses these kinds of clauses.

Anyway, they had no clear roadmap or timing for milestones in the contract. They just mentioned that once the project was ready for market release, they’d “check in” to see if working with me was still worth considering. They mentioned the possibility of offering me a percentage pay if things worked out, but it was never formalized - just a vague idea they threw out there. There were no details, no clear terms, and no guarantees, which made it hard to take seriously. It felt more like an afterthought than a genuine offer, almost as if they were testing the waters without any real commitment behind it.

What I don’t understand is that they already have several different versions of software that would be some guiding-point and instead of using that existing evaluation and iterating on the parts that are not ideal for the customerbase (such as delay of workflow, separation of concerns, third-party software, etc.), they would seek for new customers and users, bringing these non-ideal workflows to new customers - just packaged in a different UI. If you have customers and users already, you can’t pitch the new project, knowing that there are pain-points. It would be without doubt much better to demonstrate BETTER workflows to them and have a prototype software that benefits the users from the get go. It would bring fresh knowledge and give the project more room to be built for, leading to a software with actual innovation. I brought that up to the discussion to implement these workflows in such a way where the automation can be tracked and reworked much faster. Kinda like an all-inclusive software, limiting the amount of third-party tools and allowing workflows, that can give the user the implession of productivity. These ideas have been argued to be too much work to consider, since “It’s working already; why reimplement it?” and “we don’t have time to explore different implementations”.

That’s the problem: delays or denying in fixing these issues will eventually push them onto the end-users, who’ll either complain or leave. I wanted to focus on building something solid from the start, but they didn’t seem to share that vision.

Due to all these meetings and differences, the software’s roadmap faced so many delays that they eventually created a fictitious deadline, pushing for a solution that met their immediate needs while overlooking these pain points. For me, this was a missed opportunity. If you’ve already got customers and feedback, why not use that to innovate and create something truly impactful? It didn’t seem right to push a product that wouldn’t fully solve their users’ problems.

Why I Said “No”

I took two days to consider it but had to say no. Called earlier than planned (wanted to call on Monday), thinking it’d help them move on. Instead, it turned into an hour-long call where the guy got heated, tried to argue, and I had to calm him down while explaining my reasoning. To be clear, I’m not mentioning ANY names or pointing fingers. I’m not mad at anyone. The business practices just weren’t for me. This felt more like a disproportion than a genuine commitment, so I had to walk away. Tough call, but the right one.

I brought it up in calls and meetings, reminding them that I didn’t do the rewrite that for free to give, but they kept bringing up that the budget couldn’t meet my ideals — even though my research showed otherwise for the sector they operated it. Most of the numbers/practices I read online were from official sources, but I might be wrong.

Reflecting on the Decision

It’s not easy to say no, especially when you’ve invested time and effort. The rewrite project was something I was proud of, and I felt undervalued when they dismissed the time I spent on it. It made me realize that my work was seen as a tool to get the project done, not as a part of a collaborative effort.

Saying no also taught me the importance of recognizing red flags early. Unclear terms, a lack of commitment, and undervaluation aren’t things to ignore. If I’d said yes, I’d have been locked into a contract that didn’t work for me, and I’d probably regret it later.

I’ve moved on, and I’m excited about whatever comes next. Hopefully, they won’t call me back just to drag me into the same project or practices again.

Sometimes walking away is the best decision you can make, even if it’s uncomfortable. It’s better to focus on opportunities that value your skills, time, and effort. This experience reminded me that clarity and mutual respect are non-negotiables for me.