This Shouldn't Need to Be Said
You should be able to contact your developer and get a response the same day.
You should know what's being worked on without having to chase anyone.
You should receive your work on time, or get an honest heads-up if something is delayed.
These aren't extraordinary expectations. They're baseline professional behavior. The fact that so many clients have been burned by developers who don't meet these basics says more about who they hired than about the industry in general.
Here's how I actually work.
Before the Project Starts
I ask questions. A lot of them.
What exactly is broken? What should happen instead? What platform? What plugins? What have you already tried? Is there any deadline? Does anyone else need to be involved?
This isn't stalling — it's due diligence. I've seen projects where the "broken checkout" turned out to be a misconfigured Liqpay API key that takes 10 minutes to fix. I've also seen "small fixes" that revealed database corruption requiring careful migration.
I can't quote accurately without understanding the problem. If a developer quotes you without asking any questions — they're guessing.
I also set expectations before starting: what I'll deliver, by when, what's not included, what access I need, how we'll communicate.
During the Project
I respond to messages the same day. Usually within a few hours.
I send updates without being asked. Not novels — short messages like: "Looked at the database, found the issue, fixing it now, should be done today" or "Hit a complication with the Liqpay version — need another day, everything else is on track."
I test on multiple devices and browsers before calling something done. I don't push changes to the live site without testing on a staging environment first. I don't rush production deploys.
If something turns out to be more complex than expected, I say so — with an honest updated estimate — before the deadline passes, not after.
When There's a Problem
Sometimes things don't go as planned. A fix reveals a deeper issue. A third-party API has an undocumented change. The client's hosting has a non-standard configuration.
When this happens, I tell the client immediately, explain what I found, describe the options, and give a revised timeline. I don't go quiet while I figure it out. Going quiet is exactly how trust gets destroyed.
After Delivery
I don't disappear the moment payment clears.
I'm available for questions for 2–4 weeks after delivery at no extra charge. If something I fixed breaks for a reason related to my work, I fix it. If the client has a question about how something works, I answer it.
What I don't do: ongoing free support for new issues, new feature requests, or problems caused by external updates. That's a separate agreement. But I do leave the relationship in a state where the client knows how to reach me if they need more work done.
Why Other Developers Disappear
I'm not going to pretend this problem doesn't exist. It does, and it's common.
Most disappearing developers fall into one of these categories:
- Junior developers who overestimated their ability and don't know how to admit it
- Overextended freelancers with more clients than they can handle
- People who underpriced the job and ran out of motivation
- Genuinely unreliable people who shouldn't be doing client work
The pattern is almost always the same: they go quiet not because they're malicious, but because they're embarrassed, stuck, or overwhelmed — and don't have the professionalism to communicate that.
What to Look For
When you're hiring a developer, the best predictor of future behavior is past behavior.
How fast do they respond to your initial messages? Do they ask clarifying questions, or just quote a price immediately? Can they explain their plan in plain language? Do they have real references or live portfolio links?
These things matter more than their portfolio. The actual work is almost secondary compared to reliability, communication, and honesty.
A developer who responds slowly before the project starts, gives vague answers about their approach, and has no verifiable past work is showing you exactly how the project will go.
Choose accordingly.