Ask HN: How long did it take to release your side project in 2016?

I've been taking a circuitous route with a side project: first just building an open source command-line tool that scratches my own itch, and then evaluating traction from there. If companies find the tool useful, I've been keeping in mind ways to build out a SaaS/enterprise version. Or if it doesn't get much traction, worst-case at least I have something that's useful to me!

The tool is called Skeema [1] and it allows you to manage relational database schemas as code -- a bridge between git (or hg, svn, etc) and SQL DDL. You can use it to export CREATE TABLE statements from a DB to a repo, and then auto-generate and run DDL based on changes to that repo. Currently it just targets MySQL (due to personal familiarity, and the historic complexity with schema changes there), but if it's successful I could envision porting it to other DBs.

The open source CLI is still in alpha, but getting very close to a first release candidate. I've spent 9 months of working 5 to 25 hours/week on it so far.

Some unexpected challenges:

* Even for entirely text-based command-line tools, building a nice polished interface takes a lot of time! My goal has been to make Skeema's CLI paradigms immediately intuitive to users of Git and MySQL, in terms of option-handling, subcommands, and config file format. Even little things like exit code values, and STDOUT vs STDERR for different types of output, matter a lot for building CLIs that are friendly to pipelines.

* None of the existing Golang CLI/config packages were the right fit. After a couple attempts at hacking/forking popular ones resulted in overly-awkward code, I scrapped all that and wrote my own. I should have done that from the start, but it felt like yak-shaving.

* I eschewed unit testing at first, going with the common side-project wisdom of only prioritizing functionality. But as the codebase grew, I really wished I had spent more time writing tests from the start. I suspect it would have been a net time-saver vs the manual ad hoc testing I was doing initially.

[1] http://github.com/skeema ↗

We're actually launching our new SaaS for bloggers in January 2017 called the Blog Enhancement Suite, but we've spent most of 2016 working on it.

It basically allows you to plug in a community to your blog using a widget that will use the core of our community voting platform Snapzu (that launched in 2013). There are other widgets out there that bloggers can use, such as Twitter Timeline, Pinterest, Instagram, etc, but all of them are redundant, showing duplicate stuff that's already on the blog, and don't really add anything for engagement and revenue like we plan on doing.

Biggest Challenges:

1. Getting the word out (mostly for feedback at this point), so that we can continue improving our landing page so that people understand it better and see the value proposition.

2. A/B testing to figure out what works and what doesn't. This is tough because of the small sample sizes (because of challenge #1 just above) and because it requires a lot of re-writing copy/text.

Unexpected encounters:

Explainer video (still in production) is taking way longer than we thought it would, approx 3 months now.

Happy to answer any questions. Links if you want to see our service in action:

http://www.snapzu.com ↗ (platform)

http://www.blogenhancement.com ↗ (SaaS for bloggers)

For my first side project which has resulted in paying customers the whole process took quite a while. From the idea to first sale the whole process was roughly 30 months (May 2014 -> Nov 2016). There were a few false starts and most of the work was done over the last few months, but I'm glad it's made it to a real release.

What is it? It's a crowd funded user interface rewrite for an open source musical synthesizer: http://zynaddsubfx.sourceforge.net/zyn-fusion.html ↗

Challenges:

- Bug testing and regression testing a large/complex user interface was difficult as it tends to be a largely manual process

- Maintaining a multi platform codebase added a lot of extra complexity and it certainly made distribution more difficult

- Identifying what the users precisely needed was difficult as time could be spent on a number of different facets of the project

- Polishing up pieces of the application after it was functionally complete took much much longer than originally predicted

- Marketing/Estimating-the-market: Initial surveys indicated a large number of users would be willing to pay to support a replacement UI and a few hundred were on a dedicated mailing list for it. Conversion rates were much lower than expected with both the general audience and those subscribed to the sub-project specific mailing list.

I started in 2015 and launched an early access in November of 2016. The product wasn't hard to make, per se, but I was stuck in analysis paralysis. Plus I went through a bout or two of depression which took away my time as well as I was writing a book which took even more time.

My biggest challenge was not picking something and just going with it. I picked what I knew (WinForms with C#) and went with it. I ended up throwing away the UI 4 or 5 times because I just couldn't get it right. It didn't look "good enough" it just looked horrible. After I launched I just thought my UI looked horrible so I started to re-do it (yet again) but this time in WPF. My UI looks so much better, I have added more functionality to the UI and it took much less time.

So far I have two big challenges, getting a paid customer as well as accurately tracking my metrics. I have, I think, 30+ downloads of the trial since I launched early access but I'm using events in Google Analytics to track and numbers I see don't always make sense. On top of that, my analytics don't seem to make much sense either as I'm getting majority of the traffic from direct but I'm not sure why that would be.

At the end of the day, I'm looking forward to 2017 as I will have a new updated release of my product, my book will be finished and I can devote more time to getting customers.

I haven't launched, so I hope this is okay. I'm 7/mo into developing a side project called https://keygen.sh ↗, and am finally wrapping things up to launch a beta in early January. I have a few hundred people on my mailing list, so that's a plus.

Challenges I've faced:

- Getting carried away with automation: emails after certain events, marketing to users who don't convert, billing features; all of these are things I should have done post-launch.

- Writing tests. I've literally delayed the launch of the product a whole month because I didn't feel my test coverage was good enough. I should have launched the beta and then started writing tests.

- Too many features. "Hey, x) would be a cool feature!", "Oh man, y) would be super useful to my users." – Yeah, I've written and then removed so many features that I'm a little ashamed.

- Wanting to adhere strictly to the JSON API spec. I shouldn't have spent so much time making sure that it followed the spec, because in the end, it doesn't.

After reevaluating things, all I need to do is finish writing documentation so that I can roll out the beta.