It wasn’t easy for me to decide how limited the FREE version should be. Sure, I want users motivate to pay at least something, but I don’t want to oust them completely.
I hate few things in desktop apps, even I understand their purpose. I hate grayed out menu options, just because PRO version has it. I hate even more if the unavailable option isn’t distinguished at all and I learn I have to pay first only after I click on it.
I can live with some promo upon startup or closing the app, because usually I don’t do it too often. But only if it’s in a “polite” way, when I don’t have to hunt the closing window nor close automatically opened tab in my browser.
I like x day trials, when the app works fully, but my problem with trial versions is, that it has to write the start date somewhere, obviously, and this thing stays on my computer even after I got rid of the software, again – obviously, but after that it’s just garbage polluting my system.
I understand DRM solves the problem of crap residing in my computer, but I hate it nevertheless, because it usually means even more crap in my mailbox.
So, what DO I like? I like when the only limitation is I can’t finalize my work (export, render or save), but otherwise I’m freely able to do anything the program offers. After purchase there is an encrypted file with a license key and this way I do it with QetriX apps.
And some polite ads for FREE users, even many of them know how to block them. I believe users can live with tasteful and just slightly disturbing (not by contents) ones.
My usual life cycle of a new feature or even a whole new product is usually I analyze what I came up with, how it should work and what benefits it should bring or what issues it should solve.
Then I write tests for all the cases, even edge ones, which helps me to sort my thoughts about the code and the functionality itself. What I like about TDD is, that during writing all the test cases I have more time to think about it, so sometimes I find improvements for the idea or, on the other hand, a dead end.
Then I write the code, trying to fulfill all the tests I wrote. This was helpful in particular when testing QPage.parsePath, which has quite specific behavior in certain situations.
Finally, if I encounter something interesting and worth sharing during the process, I write a blog post about it. Sometimes writing the post takes more time, then the coding itself, especially if I want to create illustrations for it, which is why there mostly aren't any :-)
Sometimes it's hard to make the code, so writing a blog post about it may help to sort out the thoughts.