When freelancing / contracting a customer will typically specify functional requirements, acceptance criteria, etc, and the implementation details are in the developer's hands.

As a developer your technology choice is a balancing act between what you are most familiar with, technologically what the right tool appears to be, ease of finding coders with this skill and their expense, and a few other factors.

I'm in a situation where I have evaluated my options and selected a somewhat obscure open source technology that I believe will get me there faster, easier, and be more maintanable in the long term. It's different, but I think that that is what the requirements call for.

The customer has inquired about what I'm going to use to build the solution, and now they are concerned because they've never heard of it before. The reasons for my choice are mostly technical, whereas the customer isn't (but they know some buzzwords!). Explaining these technical reasons will not be easy, and I am not sure if that is the right way to approach this situation anyway.

And that's my question: what is the right way to approach this situation so as to cause the least amount of headache for everyone involved?

closed as primarily opinion-based by user22815, user40980, durron597, gnat, user53019 Apr 29 '15 at 15:56

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Something to keep in mind: most of the total-lifetime-cost of a system is not in the development stage, it is in maintenance. The more obscure the tech, the more likely the customer will have trouble finding people to do maintenance after you get Hit By A Bus®. As boring as PHP/MySQL might be, there are approx. 1 billion people who can work with it. Even using relatively mature projects (e.g. Django) for some websites has proven problematic over the long run. – Peter Rowell Oct 5 '12 at 17:54
  • 1
    Why do most people still buy Petrol powered cars over Electric cars? Same reason your customer does not want some obscure technology behind their software - RISK. – mattnz Oct 5 '12 at 19:44

technology that I believe will get me there faster, easier, and be more maintanable in the long term

That's how you justify it. If they don't trust you to make that evaluation then they are entitled to make it themselves. But, unless it's too late, make it clear that this affects your estimates because your estimates are based on your ability to choose the best technology for the job.

They might even decide that they're happy to take a financial hit now for the flexibility of being able to replace you with another developer later. Or, in fact, for any other reason that makes sense to them. They are entitled to make that choice. Remember that your priorities (speed, simplicity and maintenance) may not match theirs, and ultimately it's their money.


technology that I believe will get me there faster, easier, and be more maintainable in the long term

That justification will not make your proposal winner. Your proposal should meet their business requirements and be cost effective, flexible and maintainable.

What business are looking to get is; a user friendly and informative UI with robust functionality at the back-end. Thus, the customer care more about how good application will appeal to eye and make their business easier to manage.

Thus, stating that X technology will solve their business problem and it will be fast to implement will fell short with the expectations. However, convincing customer that previous convoluted menu navigation will be replaced with intuitive UI and flexible back-end engine that allow easier customization of services will be BIG selling point to accept your proposal.


A programmer is generally more equipped to know what tool (tech) is best suited for the task at hand; however, despite this your justification should not come from a programmer perspective but from your client's perspective.

That said, you need to know a little about your client and what matters to them. For example, you alluded to the fact that you chose a more obscure open source solution. If the client highly prioritizes being able to bring on run-of-the-mill developers for future maintenance this may not be a good choice as it weighs against their priority.

No matter how well suited some technology is for the technical task at hand there are business concerns that may be more meaningful to the client. Ultimately, laymen don't care about technical details, only ramifications.


As a rule of thumb, technology should be employed strictly as a means, not an end. You will always run into situations where the customer wants to have a say, regardless of their expertise or lack thereof. This is especially true in graphic design where everyone can suddenly become an art critic. Your job is to educate the customer about the decision you made and the associated trade offs. If your decision process is completely transparent and everyone is on the same page, then you can proceed with confidence. It may be the case that the customer is truly stuck on the buzzwords, in which case they may simply not be the right customer, because they if they are unreasonable in one regard there is nothing to say they won't be in another. Alternatively, the customer could have appropriate reasons for using a specific technology, in which case it becomes a requirement of the project. Overall, open and transparent communication is key.

Not the answer you're looking for? Browse other questions tagged or ask your own question.