Tag Archives: saas

Creating a forum for your product

I started selling software online 16 years ago. Until this year I never had a forum for any of my products. I handled customer support for PerfectTablePlan and Hyper Plan by email and kept customers up-to-date with an opt-in email newsletter. But I rethought this position with my latest product, Easy Data Transform and started a forum at forum.easydatatransform.com in December 2020.

My ISP offered various forum software packages, but I really wanted Discourse, as I consider it head and shoulders above all the other forum software I have interacted with as a user (even if I find the badge system a bit patronising). I didn’t want the hassle of setting up and patching a Discourse server, so created the forum through www.communiteq.com (previously discoursehosting.com). It was suprisingly easy to set-up. And it gives the option to export everything, in case I want to part ways with them. The sheer number of options in Discourse are quite daunting, but I stuck with the defaults for the most part.

Some people use Facebook Groups for their product forums. Ugh. You have almost no control of such a forum. Facebook could even be showing ads for your competitors on your forums. Or they could just decide to shut you down and delete all the content. That is before we get on to the fact that Facebook make their money monetising hatred and abusing our privacy at an industrial scale. No thanks.

The advantages of a forum are:

  • Letting customers talk to each other, and post content helps to create a community around the product. Which, in turn, can add a lot of value to your product.
  • Customers can help each other with support questions. Sometimes they will answer before you are able to or will give a different perspective. Or even give a better answer.
  • If a customer asks a question that has already been asked, you can send them a link to the appropriate forum page.
  • It is a quick and easy channel to communicate with customers. I can post a link to a new snapshot release in a few minutes. This is much quicker than sending out an email newsletter. It is also more interactive as customers can respond on the forum and see each other’s responses.
  • A lively forum is ‘social proof’ that your product is worth buying.
  • A forum with lots of content should have a large SEO footprint.

The disadvantages of a forum are:

  • The time to maintain it. A forum that is broken or full of spam and unanswered questions is worse than no forum.
  • Disgruntled customers potentially airing their grievances in public.
  • The cost of the forum.
  • An empty forum looks bad.
  • Bad actors can be a pain. For example, people posting links to spam or competing products.

It probably only takes me 1-2 hours per week to post on the forum at present. Some of that is time I would have spent answering support emails. If that rises substantially then I may have to delegate it.

I try very hard to provide a good product, with good support and haven’t had any issues with negativity, so far. But I know from my experiences moderating Joel Spolsky’s Business of Software forum that moderating a busy forum can be tricky, time-consuming and emotionally draining.

The cost of the forum is currently around $20 per month, so pretty low. That may climb, but hopefully sales will be climbing as well.

I was a bit worried about whether the forum was going to look empty. I warned customers that the forum was an experiment and would be closed if there wasn’t enough activity, to manage their expectations. I also created a ‘sock puppet’ account and ‘seeded’ the forum with a few support questions that I had been previously asked by email (with the permission of those that asked) and then posted answers. But I only did this a handful of times and then the forum started to take off.

I have heard stories of people getting 1000+ spam posts a day on their forum. But I haven’t had any issues with bad actors, so far. I’m not sure how much of that is down to Discourse and how much of it is down to luck. But, no doubt issues will occur at some point.

I still have my product newsletter, which I send out every few weeks when there is a new production release.

Overall I am pretty happy with how the forum is going. Should you have a forum for your product? As always, it depends. I think you should consider it if:

  • Your customer base isn’t tiny.
  • You want to interact with your customers and get feedback. This might be less the case with mature products.
  • You have the time and energy to police and maintain it.
  • Your product is relatively open ended or complex. For example, if your product just checks whether website are up or down, there is probably a very limited amount you can discuss.

30 tips for creating great software releases

If a film director is only as good as their last film, then I guess a software developer is only as good as their last software release. In more than 30 years of writing software professionally I have shipped my fair share of releases. For the last 13 years I have been shipping software as a solo developer. Here are a few things I have learned along the way. Some of them are specific to downloadable software, but some of them apply equally to SaaS products.

Use a version control system

I occasionally hear about software developers who don’t use a version control system. Instead they usually create some sort of janky system using dated copies of source folders or zip files. This send shivers down my spine. Don’t be that guy. A version control system should be an essential part of every professional software developer’s tool kit. It matters less which version control system you use. All the cool kids now use distributed version control systems, such as git. But I find that Subversion is fine for my requirements.

Tag each release in version control

This makes it easy to go back and compare any two releases. A bug appeared in the printing between v1.1.1 and v1.1.2? Go back and diff the source files related to printing and review all the changes.

Store your release binaries in version control

I store every binary I ship to customers in my version control system. Many people will tell you that you should only store the source in version control. Then you can use this to regenerate the binaries if you need to. This was sound advice back in the day when harddisks were small, networks were slow, version control systems were clunky (SourceSafe!) and developer environments didn’t change very frequently. But I don’t think it is valid advice now. Harddisks are as cheap as chips, networks are much faster and online updates mean your SDK, compiler or some other element of your toolchain is likely to be updated between your releases, making it impossible for you to recreate an identical release binary later on.

‘Test what you ship, ship what you test’

In an analog system (such as a bridge) a tiny change in the system will usually only cause a small change in the behaviour. In a discrete system (such as software) a change to a single bit can make the difference between a solid release and a showstopper bug. The Mariner I rocket was destroyed by a single missing hyphen in the code. So test the binaries that you plan to ship to the customer. And if you change a single bit in the release, re-test it. You probably don’t need to run all the tests again. But you certainly can’t assume that a small change won’t cause a big problem.

This issue often manifests itself when the developers test the debug version of their executable and then ship the release version. They then find that the two have  different behaviour, e.g. due to a compiler optimization, different memory layout or code inside an ASSERT.

Make each executable individually identifiable

As a corollary of the above, you need to be able to uniquely identify each executable. I do this by having a timestamp visible in the ‘About’ box (you can use __DATE__ and __TIME__ macros in C++ for this) and ensure that I rebuild this source file for every release.

Diff your release with the previous one

Do a quick diff of your new release files versus the previous ones. Have any of the files changed unexpectedly? Are any files missing?

Be more cautious as you get nearer the release

Try not to make major changes to your code or toolchain near a release. It is too risky and it means lots of extra testing. Sometimes it is better to ship a release with a minor bug than fix it near the release and risk causing a much worse problem that might not get detected in testing.

Test your release on a clean machine

Most of us have probably sent out a release that didn’t work on a customer’s machine due to a missing dynamic library. Oops. Make sure you test your release on a non-development machine. VMs are useful for this. Don’t expect customers to be very impressed when you tell them ‘It works on my machine‘.

Test on a representative range of platforms

At least run a smoke test on the oldest and most recent version of each operating system you support.

Automate the testing where you can

Use unit tests and test harnesses to automate testing where practical. For example I can build a command line version of the seating optimization engine for my table plan software and run it on hundreds of sample seating plans overnight, to test changes haven’t broken anything.

If you set up a continuous integration server you can build a release and test it daily or even every commit. You can then quickly spot issues as soon as they appear. This makes bug fixing a lot easier than trying to work out what went wrong weeks down the line.

But still do manual testing

Automated test won’t pick up everything, especially with graphical user interface issues. So you still need to do manual testing. I find it is very useful to see real-time path coverage data during testing, for which I use Coverage Validator.

Use third parties

You can’t properly test your own software or proof read your own documentation any more than you can tickle yourself. So try to get other people involved. I have found that it is sometimes useful to pay testing companies to do additional testing. But I always do this in addition to (not instead of) my own testing.

Your documentation is an important part of the release. So make sure you get it proof read by someone different to the person that wrote it.

Use your customers

Even two computers with the same hardware specifications and operating system can be set up with an almost infinite range of user options (e.g. screen resolutions, mouse and language settings) and third party software (e.g. anti-virus). Getting customers involved in beta testing means you can cover a much wider range of setups.

When I am putting out a major new release I invite customers to join a beta mailing list and email them each time there is a new version they can test. In the past I have offered free upgrades to the customers who found the most bugs.

Don’t rely only on testing

I believe in a defence in depth approach to QA. Testing is just one element.

Automate the release process as much as you can

Typically a release process involves quite a few steps: building the executable, copying files, building the installer, adding a digital signature etc. Write a script to automate as much of this as possible. This saves time and reduces the likelihood of errors.

Use a checklist for everything else

There are typically lots of tasks that can’t be automated, such as writing release notes, updating the online FAQ, writing a newsletter etc. Create a comprehensive checklist that covers all these tasks and go through it every release. Whenever you make a mistake, add an item to the checklist to catch it next time. Here is a delightfully meta checklist for checklists.

Write release notes

Customers are entitled to know what changes are in a release before they decide whether to install it. So write some release notes describing the changes. Use screen captures and/or videos, where appropriate, to break up the text. Release notes can also be very useful for yourself later on.

Email customers whose issues you have fixed

Whenever I record a customer bug report or a feature request, I also record the email of the customer. I then email them when there is a release with a fix. It seems only polite when they have taken the effort to contact me. But it also encourages them to report bugs and suggest features in future. I will also let them access the release before I make it public, so they can let me know if there are any problems with the fix that I might not have spotted.

Don’t force people to upgrade

Don’t force customers to upgrade if I don’t want to. And don’t nag them every day if they don’t. A case in point is Skype. It has (predictably) turned from a great piece of software into a piece of crap now that Microsoft have purchased it. Every release is worst than the last. And, to add insult to injury, it just keeps bleating at me to upgrade and there doesn’t seem to be any way to turn off the notifications.

Don’t promise ship dates

If you promise a ship date and you get your estimate wrong (which you will) then either:

  • You have ship software that isn’t finished; or
  • You miss your ship date

Neither are good. So don’t promise ship dates. I never do and it makes my life a lot less stressful.  It’s ready when it’s ready. I realize that some companies with investors, business partners and large marketing departments don’t have that luxury. I’m just glad that I am not them.

Inform existing customers of the release

There isn’t much point in putting out releases if no-one knows about them. By default my software checks an XML file on my server weekly and informs the customer if a new update is available. I also send out a newsletter with each software release. I generally get a spike in upgrades after each newsletter.

Don’t release too often

Creating a stable release is a lot of work, even if you manage to automate some of it. The more releases you do, the higher percentage of your time you will spend testing, proof reading and updating your website.

Adobe Acrobat seems to go through phases of nagging at me almost daily for updates. Do I think “Wow, I am so happy that those Adobe engineers keep putting out releases of their useful free software”? No. I hate them for it. If you have an early stage product with early-adopters, they may be ok with an update every few days. But most mainstream customers won’t thank you for it.

Don’t release too infrequently

Fixing a bug or usability issue doesn’t help the customer until you ship it. Also a product with very infrequent updates looks dead. The appropriate release frequency will vary with the type of product and how complex and mature it is.

Digitally sign your releases

Digital certificates are a rip-off. But unsigned software makes you look like an an amateur. I am wary of downloading any software that isn’t digitally signed. Apple now prevents you downloading unsigned software by default.  Signing is just an extra line in your build script. It is a bit tedious getting a digital certificate though, so get one that lasts several years.

Check your binaries against major anti-virus software

Over zealous anti-virus software can be a real headache for developers of downloadable software. So it is worth checking if your release is likely to get flagged. You can do this using free online resource virustotal.com. If you are flagged, contact the vendor and ask them to whitelist you.

‘The perfect is the enemy of the good’

Beware second system effect. If you wait for perfection, then you will never ship anything. As long as this release is a significant improvement on the last release, then it is good enough to ship.

Pace yourself

Creating a release is exhausting. Even maths, physics and software prodigy Stephen Wolfram of Mathematica says so:

I’ve led a few dozen major software releases in my life. And one might think that by now I’d have got to the point where doing a software release would just be a calm and straightforward process. But it never is. Perhaps it’s because we’re always trying to do majorly new and innovative things. Or perhaps it’s just the nature of such projects. But I’ve found that to get the project done to the quality level I want always requires a remarkable degree of personal intensity. Yes, at least in the case of our company, there are always extremely talented people working on the project. But somehow there are always things to do that nobody expected, and it takes a lot of energy, focus and pushing to get them all together.

So look after yourself. Make sure you get enough sleep, exercise and eat healthily. Also things may be at their most intense straight after the release with promotion, support, bug fixing etc. So it may be a good idea to take a day or two off before you send the release out.

Don’t release anything just before you go away

There is always a chance a new release is going to mess things up. If you are a one-man band like me, you really don’t want to make a software release just before you go away on holiday or to a conference. Wait until you get back!

Fix screwups ASAP

We all make mistakes from time to time. I recently put out a release of my card planning software, Hyper Plan, that crashed on start-up on some older versions of macOS. Oops. But I got out a release with a fix as soon as I could.

Treat yourself after a release

Releases are hard work. A successful release deserves a treat!

Anything I missed?

 

 

South West Bootstrappers meetup

I am organizing a regular meetup in Swindon (UK) for people who are running (or are interested in running) their own bootstrapped (i.e. not VC funded) software product business. Come along and talk shop with other aspiring and experienced bootstrappers. It doesn’t matter if you are developing for web, Windows, Mac or mobile.

The first meetup is on the evening of Tuesday 16th June 2015. You can find out more and RSVP at meetup.com/South-West-Bootstrappers/.

swindon meetup

Is desktop software dead?

desktop vs webIt’s rare that I chat to other software developers without someone asking me when I am going to do a web version of my seating planner software. Because the market for desktop is dead, right? SAAS apps is where all the action is!

I think the web is a great platform for some products, not so much for others. Let’s look at the advantages of web apps over desktop apps.

Web advantage 1: No installation

You can access a web app from any device that has a browser. No need to install. There is no doubt this is a major convenience. However most desktop utilities can be downloaded and installed in 1-2 minutes with a decent broadband connection. Also you don’t have to keep logging in to most desktop apps, once they are installed.

Web advantage 2: No upgrades

End-users are always using the latest version. This is definitely an advantage for technical support. But it does take away some choice from the user. Perhaps they weren’t ready to upgrade or preferred the old version?

Web advantage 3: Better user insights

You can analyse how users are using your software. This allows you to improve usability and send out tailored lifecycle emails. It is possible to gather similar information for desktop software, but it involves a lot of extra work.

Web advantage 4: Distributed architecture

If you are writing web apps, you get a distributed architecture for free. No need to do socket programming.

Web advantage 5: Less piracy

Cracks and keygens are a fact of life for desktop software vendors. It is easier to protect against piracy with a web app.

Web advantage 6: Cross platform

In theory web apps are cross-platform. Write them once and they can run on any device with a browser. But browser compatibility issues mean it isn’t that easy in practice, especially if you are still forced to support the dreaded IE6. Also there are solutions (such as Qt) that allow you to deploy to multiple desktop devices from a single code base.

Web advantage 7: Subscriptions

Web apps lend themselves to subscription based payment. This is great because you get a more predictable monthly income and potentially get more money from each customer over the lifetime of the product.

So what about the advantages of desktop apps over web apps?

Desktop advantage 1: Responsiveness

Native apps are more responsive than web apps, partly due to lower level access to the machine and partly due to not having to talk to a remote server. However this advantage is eroding as bandwidth and JavaScript performance improves and more work is carried out by the client in web apps (e.g. using Ajax).

Desktop advantage 2: Reduced hosting costs

The costs of hosting a website for a desktop app is minimal. Typically you just need to serve a few pages and a download file to each visitor. They then won’t need to come back until there is an upgrade. But hosting costs can be significant for a web app, particularly if the app requires large amounts of bandwidth or compute power.

Desktop advantage 3: Better access to hardware

Desktop apps can make better use of the hardware available. For example, you can generally do printing a lot better from a desktop app.

Desktop advantage 4: Better development tools

The old joke is that JavaScript is to Java as the Taj Mahal curry restaurant is to the Taj Mahal. As a C++ developer I am used to working with a fully fledged IDE, debugger, profiler, static analyser and runtime coverage analyser. I tried some JavaScript development recently. Ugh. The development tools seemed very primitive and  JavaScript is a language so hideous that surely even it’s mother couldn’t love it. No classes, no strong typing, no templates and broken scoping. However frameworks such as jQuery have made JavaScript much more accessible over recent years.

Desktop advantage 5: Psychological

Many people feel that anything web-based should be free. Psychologically customers seem more ready to pay for desktop software. Perhaps they feel a greater sense of ownership. This perception is gradually changing for B2B, but I think it is still prevalent for B2C.

Desktop advantage 6: Privacy

Many customers don’t feel confident storing important and confidential information on third-party servers.

Desktop advantage 7: Availability

You can’t use a web app unless the server is up and you have an Internet connection. A desktop app installed on your local machine is always available. You can continue to use it, even if the vendor goes out of business.

Desktop advantage 8: Up-front payment

Desktop apps lend themselves to a single, up-front payment. This is great because you get all the money straight away, improving your cash flow.

So I have come up with similar number of advantages for web apps and for desktop apps. Which is better? It depends, of course. For my particular application, I think a desktop app still has significant advantages:

  • My software can render and zoom in and out of large floor plans better than my web based competitors.
  • I use a genetic algorithm to assign guests to seats. It makes more sense to use under-utilised desktop CPUs for this, rather than me having to pay for a beefy compute server. The thought of writing a genetic algorithm in JavaScript is too awful to contemplate (although Atwood’s law dictates that someone will, if they haven’t already).
  • I can do printing better than my web-based competitors.
  • Most of my web-based competitors seem very feature-poor. I am sure that is at least partly due to poor tooling for web development compared to desktop development.
  • Most of my web-based competitors give their product away for free in the hope of making some money back on ads. I charge for mine.
  • Seating plans can contain sensitive information, particularly for events with celebrities, royalty and heads of state. Some of my customers don’t want this information transmitted to and stored on third-party servers.
  • If my server goes down then I lose sales. But my customers can continue to use my software. Imagine if they were dependent on my server and it went down (or I went out of business) the day before their big event. It brings me out in a cold sweat to think about it.

But other products are a better fit for the web. If I was writing a collaborative CRUD app, I would almost certainly do it as a web app. I have recently been working on a couple of new products. One is a web app and the other is a desktop app. Horses for courses.

A lot of the money I have spent on software over the last few years has been for desktop software. When I had to choose bookkeeping software, I chose a desktop package because I didn’t want to:

  • pay every month
  • store sensitive financial information on a third-party server
  • risk losing all my data if the vendor went out of business

If I look through the list of useful tools and services on this site I see that 51 of them are web-based and 35 are desktop based. Peldi of Balsamiq reported in 2009 that 77% of their revenue comes from the desktop versions of their software. I asked him if that had changed much and he was kind enough to send me the following graph (myBalsamiq is the web version). You can see that it is still nearly 70% 4 years later.

desktop vs web

The line between desktop and web apps is also becoming more blurred. Many desktop apps now use web protocols and embed web browsers. For example, the Qt toolkit allows you to easily create applications that are hybrids of desktop and web. It is also possible to sell a web app that companies host on their own servers. This adds some of the advantages and disadvantages of a desktop app compared to a web app installed on the vendor’s server (SAAS). Perhaps desktop and web apps will converge to the point where there the whole desktop vs web debate becomes meaningless.

So I think reports of the death of desktop software have been greatly exaggerated. There is no doubt that long-term trends ( e.g. increasing bandwidth and attitude to paying for web apps, for B2B at least) have been changing the balance in favour of web apps for some types of product. Particular those where collaboration is more important than graphics or computer power. But I think there will continue to be plenty of markets where a desktop app is a better choice than a web app for the foreseeable future. In the final analysis, customers care a lot more about how well your software solves their problem, than how it happens to be deployed (if they even understand the difference).

Boostrapped.fm podcast

I was a guest on episode 21 of Bootstrapped.fm, the podcast of Andrey Butov and Ian Landsman. The discussion was very wide-ranging, touching on SAAS vs web, the Qt development environment, the royal wedding, A/B testing, capoeira, Adwords, the history of shareware, my new training course and lots more besides. I really enjoyed it. Boostrapped.fm also has a thriving discussion forum at discuss.bootstrapped.fm.

80 useful tools and services for software businesses

tools and servicesSome of the most useful nuggets of information I come across in blogs and podcasts are mentions of tools and services used by other people to better run their software businesses. So I have put together my own list of useful tools and services to run a software business.

Feel free to recommend your own favourites in the comments below. Please include your relationship to the tool/service (e.g. customer, user, employee or owner). You can also comment below about your experiences (positive or negative) with any of the tools and services listed. Anonymous comments will be treated with suspicion and may be deleted