The meeting goes well. You explain the scope, align on the budget, talk through the timeline. Everything is moving forward. Then, right at the end: "Actually โ my cousin does websites. Let me check with him first."
That sentence has stalled more projects than budget constraints ever have.
What "does websites" means
The cousin probably exists. He probably can build a website โ WordPress, maybe something custom, maybe he's picked up freelance work on the side. That's real, and there's a legitimate market for it.
The problem is what you're actually asking him to build. Not a landing page. Not a five-page company site. A custom client portal, an operations dashboard, a booking system, an inventory application that needs to run reliably for the next five years.
"Does websites" and "builds software" are different professions. Not different levels of the same profession โ different professions. A general contractor and an architect both work on buildings. You wouldn't hire one to do the other's job.
The three ways it usually ends
I've seen this play out enough times to recognize the patterns.
The cousin says no
He looks at the actual scope, realizes this is not a theme swap, and quietly backs out. Two weeks passed while you waited. The momentum is gone. Back to square one.
The cousin says yes โ but shouldn't
This is the expensive path. He takes it on, probably for free or very cheap because it's family. Things start. The deadline moves. Life gets in the way โ his full-time job, other commitments, a problem he doesn't know how to solve and won't admit. Months pass. When you finally see what's been built, it's either incomplete, fragile, or not quite what you described.
And now you're in the worst position possible: this is family, so it's difficult to say anything directly.
The cousin does a fine job โ on the right scope
A small site, a contact form, a clean digital presence. This happens. It's legitimate. It's not the problem.
The problem is when you confuse this with the scenario above, because to a non-technical person the two sound like the same thing.
What you're actually risking
When the stakes are low, the cousin arrangement is fine. When this software is going to run your business, you're risking more than the money you're trying to save.
The timeline. A freelancer or family developer has no contractual accountability, no team to delegate to, and no obligation to prioritize your project over everything else in their life. When something comes up โ and something always comes up โ your project waits. Nobody tells you.
The code. Good code is maintainable. Documented, structured so another developer can pick it up later. A solo developer with no professional obligation to future readability will often produce something that works right now and is nearly impossible to hand off. When that person moves cities, changes careers, or just loses interest, you're holding code that nobody else can open without three hours of archaeology first.
The relationship. When a vendor fails to deliver, you end the engagement. When your cousin fails to deliver, you still see him at every family dinner for the next decade.
The cousin isn't the problem. Hiring the cousin for the wrong scope is the problem.
Why this keeps happening
In Lebanon especially, business runs on personal networks. You hire who you know, trust family referrals, and treat professional relationships as extensions of personal ones. That's not a flaw โ it's how you navigate a market where credentials are hard to verify and contracts are harder to enforce.
But software is a context where that logic breaks down. "My cousin is smart and reliable" doesn't translate to "my cousin can build a production-grade application." His personal character โ however excellent โ doesn't change what he's technically capable of delivering.
The other factor is cost. A cousin does it for free or nearly free. A professional company charges real money. In a market where every expense needs to be justified twice, choosing the free option looks responsible. It rarely turns out to be.
When the cousin is actually the right answer
We're a custom software company. We regularly tell clients that custom software is the wrong answer for them. This is the same kind of honesty.
If you need a business card website โ five pages, contact form, clean design โ and your cousin builds those well, hire the cousin. Fast, cheap, low stakes, and if something needs fixing later it's a manageable problem.
But if you need any of the following, you're past cousin territory:
- User accounts with roles and permissions
- Data that needs to be reliable, structured, and recoverable
- Integration with payment gateways, ERPs, or external APIs
- A product other people will use and pay for
- Something that needs to keep working after the person who built it is no longer reachable
The honest test: if the software failing would meaningfully hurt your business, it needs to be built by someone whose professional existence depends on not failing.
