How not to sell your software
Sometimes the answer to the "Buy vs. Build" question is "Buy." Buying, of course, means evaluating multiple vendors and then picking up the best solution for a specific need.
You can find articles on how to sell your software anywhere. Here is the list of things you can do if you would rather keep it all to yourself.
Don't tell anybody what your product does
Put up a modern scrollable page. Use words like Synergy, Breakthrough, Revolutionary, Digital Transformation, Automation, and Cloud. Bonus points for mentioning AI.
Include loads of images of people laughing or staring at the computer monitor.
Provide very little detail but solicit emails if your potential buyer still wants more information. Doing so will filter out the competitors who are trying to steal your ideas.
Never show pricing
If you need to ask, you can't afford it. Solicit emails for pricing inquiries, then insists on setting up a sales call. Nobody is THAT busy when they are evaluating multiple solutions, and your product is too complicated to be priced at a single rate.
Bonus points for coming up with an extra convoluted pricing model and then offering oddly specific discounts, like "13.5% off if you purchase the annual plan within the next 17 hours". That creates a sense of urgency, which makes your software sell itself.
Write "some" content. Redirect all questions to it
Write a few helpful articles and then program an online chatbot to respond with even slightly relevant URLs. If someone asks to clarify, it does not mean they have a specific question that your documentation didn't answer. Your bot should humorously respond that documentation intended to be read, and they advise you to review it again at the link above.
Do not provide any other ways of contacting you with the product questions.
Do not offer DIY demos
Your product should only be shown by a qualified sales professional who knows the correct click sequence. Trial and demo modes lead to trouble, more questions, and competitors stealing your idea.
If a question does arise during the demo, the sales rep should joke about not being good with computers and offer to create a ticket for a "staff engineer" to get back to you.
Do not create a ticket.
Call all day every day
Once you obtain a lead, never let it die. Email or call as frequently as possible. Create a sense of urgency. Say that the licensing fees are about to triple, but if you close today, the old prices will apply.
Use tried and true technology
If something had worked ten years ago, why go seeking trouble? Your interface should never change; it just confuses users. If your product depends on some other product, like Crystal Reports, pick a version and stick with it. Forever. Upgrading is a sign of weakness.
Doing so forces your customers to go back to their roots - specifically, a decommissioned computer running an unsupported version of OS that can still run your product. It's good to remember the history.
Provide the best experience
Encryption makes things slower - that's a fact. Password hashing makes providing passwords to users difficult. Insists that nobody will be spending time hacking your software because it never happened before, and you are too small to matter. Point out that even the most secure software gets hacked.
Bond with your users
It could be intimidating looking at the polished website. Be approachable, like a friend next door - add a few spelling errors, never change your site design, do not use SSL.
Bonus tips if you got a customer
Someone still bought your software?
Provide choice
There should always be multiple ways of accomplishing a taskâonly some of them should be tested or documented. It's fun to be surprised.
Create a very complicated installer
If your product is a desktop solution, insist that a highly trained technician must install it. A single wrong answer during installation should be catastrophic, corrupting freshly installed software and requiring a reinstall.
Bonus point if this experience can be repeated during software updates AND if these updates are forced on a very frequent schedule. Do not call those "bug fixes." Boast that you are an agile company and believe in continuous delivery.
Teach your users to unplug
If someone leaves your application running overnight, but you decided to apply an automated patch, immediately destroy the shared data storage. Ignore that your software can see the opened connections.
Improve customer experience
Make it impossible to contact the human for support. Require proof of extensive training on how to use your software before talking to the customer having the problem with your software.
Better yet, replace all humans with an improved portal where AI can randomly pick answers from your sparse documentation. Claim this is done to improve the service.
Only fix a limited amount of bugs per year. Make your users fight with each other, deciding whose bug is more critical to address.
Who are you creating for?
It's easy to get lost in requirements, technical implementation, architecture, and testing. It's easy to dismiss UX as something that would be nice to have, but you don't have time for it because the project is already delayed, and decide that brief and outdated documentation would do.
Software project doesn't end with final production push - you still need to maintain, support your users, post bug fixes, and provide security updates.
The tolerance for bad software has been high - we tend to be much less forgiving of glitchy appliances or electronics. That tolerance is slowly going away as new players coming to the market with better, easier, and more robust solutions.
Before you start designing the new project- or deciding to refactor an existing one - think about your customer's experience and how it could be improved. Make software that is a joy to use.