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?
2
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.