My latest project

Today feels like a special day. The reason is that the project I have been working on for a couple of months now has been released for alpha testing. I encourage everyone to check it out at http://visitmeadow.com

The whole event planning thing was sort of a pet peeve of mine for a while. It was the worst when I had to plan a vacation or something of that sort, but even making arrangements for a barbecue sometimes felt like a mess. I mean, we would lose important information and agreements, forget something important. We would also have to use a ton of different applications. I mean, at least there's a facebook group to chat. A facebook event, if we want a convenient place to store the time and location. Then evernote if we need a check-list or something. Dropbox if we need to store a file or several. Some table to keep track of expenses. The list goes on.

So, naturally, I was very excited to make an application that should help deal with this type of problem, and I sure hope we are not the only people who keep having it.

The project is also quite a pleasure to work on from a technical perspective. Getting to choose any tech stack was like a breath of fresh air after a couple of projects with legacy requirements. The only decision I'm not quite sure about is AngularJS. I mean, I really like the framework, but it seems like it is in some sort of transition to version 2.0 which will break backward compatibility.

Anyway, the project is far from over and many important features are yet to come. Will try to keep you updated on any interesting developments!

The Pragmatic Programmer

I read a lot. It's a habit I've developed early, and I have no intention to abandon it any time soon. I read books, I read the news, I read blogs, I read various articles and tutorials. Basically, anything that manages to catch my eye.

When it comes to programming, most of my reading comes from the Internet. The main reason (apart from convenience) is that in such a dynamic area I like to get my knowledge from the most up-to-date sources possible. Books on programming, unfortunately, tend to become outdated quickly. Not all books, however. There are a few that will likely remain relevant for many years to come. I've recently finished reading one of such books - "The Pragmatic Programmer: From Journeyman to Master" by Andrew Hunt and Dave Thomas.

I found it to be an amazingly useful book. Even though it was published waaay back in 1999, it is still very relevant because it does not focus on any specific technology. Instead, it examines the core process - understanding what your clients want, and turning that requirement into working, maintainable code. As stated in the books description, it covers topics ranging from personal responsibility and career development to architectural techniques for keeping your code flexible and easy to adapt and reuse.

Of course, a lot of the stuff described is pretty obvious. However, I would not necessarily call that a flaw. It's still invaluable information for beginners, and for the more experienced programmers, the book helps organize the methods and concepts into a neat structure.

To sum up, I would say this book should be a must-read for anyone who wants to be a good programmer. It won't magically turn your bad code into awesome code, but it might as well give you a push in the right direction.

My projects

It occurred to me today that I have been really busy lately. Whenever I'm not working on freelance projects or doing consultancy work (apparently, it's not so easy to escape my previous career), I am working on one of my own projects. Which seems exciting to me. So I decided to make a brief summary of the stuff I finished already and the stuff I am currently working on.

I publish my finished software under the Bearson Software trademark (link). I mostly work on it alone, with the occasional help of a designer and a marketing specialist. So far, this is what I have:

Certification manager 2015 (Github). This is a niche tool for MRO (maintenance, service and overhaul) service companies in the aviation industry. This was my first project, and it lead to an order from one of such companies for a improved and customized version.

The main purpose of the application is to a) keep track of employees and their personal information; b) keep track of training and certification of the employees. Other functionality includes import and export of data (xls/xlsx) and report generation.

Pure list (Github, Google play). This is an Android to-do list and task manager. It provides basic functionality for this type of app (multiple lists, item reordering, marking items done, reminders) plus a home screen widget. The main selling point is the clear and intuitive design, which is customizable with several themes.

As for the current projects, I have several ideas that I am testing out before making a fully functional version. I will try to update this post as soon as it takes some defined shape.

On choosing a price for software

Good evening, fellow readers!

Yesterday, I finished a large commercial application and finally launched it. I spent about a month developing it, and then a couple of weeks setting up a website, testing payment methods and so on. As of yesterday morning, there was only one decision I still hadn't made - how much should I charge for a licence? I didn't want to make it so expensive that no one would buy it, but I obviously didn't want to underprice it either. Now, I may be wrong, but perhaps the decision would be easier if the application was targeted at a consumer market (it is not).

As an economics major, I knew the basics. However, that does not help much because, a) software is different from other products due to the fact that it does not have any variable costs (i.e. creating one instance of the application costs me the same as creating ten million); and b) economic theory works best when your customers are perfectly rational decision-making robots (which, I assume, my customers are not). So, naturally, I had to do some research.

Unfortunately, no source told me how much my software should cost. However, there was some advice, that I found useful. Here it is:

1) Perceived value is not the same as objective value
From a logical point of view, if a product saves you 5 hours of your time, and you value your time at $20 per hour, you should be willing to pay anything under $100 for that product, assuming you have nothing better to spend that money on. However, how many of you actually make such calculations? For most people, purchasing decisions are made based on the perceived value of a product, which can be influenced presentation, marketing pitches and testimonials - and, surprisingly by the price.

2) The price sends a message to the customers
A product for $10 is perceived differently than a similar product for $100. Underpricing software is dangerous not only because it can decrease revenue, but also because it can trick customers into thinking that the application is useless or low-quality.

3) The product is more than the product 
People pay for the experience of dealing with a business, not just for the software itself. So, the price should depend on the objective reality of the whole operation - starting from the marketing pitch and finishing with the support that is provided.

4) Price tiers help - but at a cost
By offering several price packs, not only do you give the client a choice, but you also provide a point of reference (also, importantly, one that does not involve looking at the prices of competitors). However, multiple prices mean more complexity for the marketing, a more complicated support infrastructure and, potentially, more confusion for the clients.

All in all, choosing the price is still no easy endeavor. Fortunately, as with most things, you can test different options and see what works best. I have decided to go with A/B testing, where several groups are made the same offer at a different price to see which responds better.