timothy89

At UserApp, Robin Y. is known as "Mr. Typo". He will be performing 100 spell checks in 100 days.

I see your point, and many of my later "hacks" has been improved since my first ten. But it also depends on who's definition we use. Most of my "hacks" includes coding (i.e. hacking) and are meant to increase growth. Are they considered growth hacks then? Or must something be "hacked" for it to be called growth hacking?

Actually most hacks are about user acquisition, but there's also retention hacks :)

Yes, that may be true, but the others could still contribute to growth. And it would be really hard (and probably not even good) to come up with 100 "true" growth hacks, and perform them one day after another ;)

Thank you, glad you liked it :) You can follow me here: http://timothy.userapp.io or on twitter: https://twitter.com/timothyej

Believe it or not, but this whole "stunt" (including this deck) hasn't generated that many signups in the long run. The best of my "hacks" would be creating the AngularJS module (http://timothy.userapp.io/post/69135125206/day-25-minimizing...) and then writing about it on Stack Overflow (http://timothy.userapp.io/post/70136752527/day-31-answering-...).

Agree! I do actually work on more deeper problems. At the moment I spend a lot of time creating integrations, improving the documentation and the getting-started guides. As we do get new signups every day, I want more of them to get started and really using UserApp. But to learn how I can improve all that I need feedback, and things takes time. Meanwhile I wait for feedback and test results I spend my time trying to improve conversion rates on the website and to drive more traffic, etc.

Here are a few of my more important "hacks":

[How to guarantee continued operation for an SaaS startup](http://timothy.userapp.io/post/67053194467/how-to-guarantee-...)

[Day 25: Minimizing integration times](http://timothy.userapp.io/post/69135125206/day-25-minimizing...)

[Day 26: Codecademy course](http://timothy.userapp.io/post/69292858355/day-26-codecademy...)

[Day 30: A/B testing getting-started guides](http://timothy.userapp.io/post/70034047713/day-30-a-b-testin...)

[Day 31: Answering questions on Stack Overflow](http://timothy.userapp.io/post/70136752527/day-31-answering-...)

[Day 32: Customer development survey](http://timothy.userapp.io/post/70245235839/day-32-customer-d...)

Thanks for your feedback. Not all of them are UI stuff, e.g the survey, the open-source warranty and the email where I asked why users had canceled. And these was the first 10, now I'm at day 36 and all of them are not about just UI. But I see your point, and the problem is mostly to be able to pull off one hack each day, many would have to be simple and easy to do, and therefore lower quality.

Regarding what actually is a growth hack or not, if it has to be new, none of my 35 hacks are a growth hack. Sharing stuff on social media would be social media marketing, blogging would be content marketing and SEO, and more fundamental "hacks" would be either a part of a business plan or just a marketing strategy.

However, my main goal of many of the things I do is to increase growth, both direct and indirect.

Very nice! This inspired me to create my own Merry Christmas "card" in CSS: http://codepen.io/userapp/full/DbhnB

Merry Christmas!

True that. Will maybe give it a try this month :)

I know what you mean. Many of the hacks' results may collide. I wonder what a possible solution to that problem could be?

I will give this a thought and see how I can plan my upcoming weeks. I have considered about canceling my every-day growth hacks to focus more on larger "hacks", and also finding users and helping them getting started. Let's see what happens :)

Thank you for your advice!

Yes, we are working on that :) The user authentication stuff maybe take a few hours/days to get in place for a experiences developer. However, what we want to focus on is everything else around user management. That's why we are building an add-on store for third-party integrations. Some example cases that we could solve:

* If you have users, you might want to sync them to e.g. MailChimp.

* You would probably want to charge them for using your app, so you would need to integrate a payment provider, calculate payments, creating price plans, etc. UserApp already takes care of all that except the payment processing, which will come as add-ons later.

* Social login (OAuth) to support login from Facebook, Twitter etc.

* Send welcome emails, forgot password emails, etc.

* An admin interface t be able to delete, block, search and manage your users, permissions, etc.

And this is not just for mobile apps. It's for every web, or mobile, app that has users to manage.

Thank you for your feedback!

I really like your advice! Others have actually told me the same and I understand "the concept". But I would like to ask you for some more advice: how can I spend my days only focusing on getting users to use us? We are already emailing every new signup offering them help etc, and some respond with questions, which we help them with. But that usually doesn't take the whole day. I would like to know some activities on how to get more of those. Cold calling?

Otherwise, thank you for your feedback. Appreciate it :)

Good idea, will see what I can do. Thanks!

I hear you. But some are hard to measure and some just takes longer than a few days to show results. I will probably follow up on the earlier rounds, and maybe also update the posts as well with the results. Though for every day there's one more "hack" to follow up on.

I will give this a try (along with other ad networks as well) when I've got the conversion rates to a better level.

Yeah I know, the problem is to find time to do one large "hack" each day. Do you have any tips for me?

Thanks, will look into that. You don't happen to know what it might cost? Maybe I should apply for a free quote :)

Our decisions (including this one) is based on what's best for our company and customers, not any future VCs. And also, this clause is mainly an insurance for our customers during our first "risky" years. Hence the expiration on the clause (October 31, 2015).

Anyway, thanks for your feedback :)

I answered you comment on by blog :)

"At the moment I'm tracking clicks on the title "Open-source warranty". But I will try to perform an A/B test later."

Great feedback!

Of course it wouldn't be totally friction-less. But as we see it it would be very easy in contrast of writing the user management all by your own. And regarding updates etc. - that is something they would have had to to with their own systems as well (considered they had written their own user management).

As I mentioned in a couple of other replies, IF this were to happen we would of course make it very easy for our customers to continue on by giving them instructions, documentation and nicely packaged as an AWS instance (or other formats).

This might not suit all SaaS's and would mostly be useful for SaaS that are developer focused (as we are).

However, appreceate your feedback :)

The problem we face is that it can be hard to migrate from our service once integrated. If course this is something that we want to improve, for example we've added the availability to export all your data. But then there's the problem with a few similar competitors to change to.

But as I wrote in another reply we would of course make it as simple as possible and probably provide the system as an AWS instance. But sure, it won't not be totally friction-less.

I will try to improve the clause based on all the feedback I've got today.

Thank you! We will do everything in our power to not ever have to use the clause ;)

The concept/clause is something that we will refine to make it as "perfect" as possible.

Appreciate your kind comments :)

http://images.wikia.com/horadeaventura/es/images/3/30/919px-...

Thank you very much for you feedback.

As I see it; either we (the founders) could feel safe knowing that the source belong to us whatever happens. Or our customers could feel safe knowing that they can continue their operation without us. We've decided to go with the latter.

I guess time will tell... :)

>What happens in an acquisition where the parent company is interested in some parts of the technology you built?

One solution would be to not sell the company for the technology only. And the clause mentioned in the blog post is only valid if there is no intent of further operation. An acquisition would be considered as intent.

The purpose is to make our customers that depend on us to feel comfortable knowing that the service would still be available for them in another form whatever happens to UserApp.

This is something we will have in the future, a "on-premise/enterprise" solution. Though it will cost a bit more than $9 a month :)

Sounds very interesting :) Will investigate the alternative. Thanks for the feedback!

(I'm the one that wrote the blog post)

Thank you for your awesome feedback. I believe that this could be done fairly easy with UserApp. We've built the system using well-known technology and standards and haven't bought any third-party software that has been integrated into our code.

The clause is not clear about everything. The code would of course be released in the same state as when we are developing in it. If of any reason we would have to close down, why would we want to make it hard for our customers? In that case we would probably give it out as an AWS instance together with instructions and documentation.

And you are right about the open-source license - we definitely need to clarify that. It will probably be under MIT.

Thank you for your support :) Will be interesting to see the final results after 100 days.

Does anyone know why I just dropped several points? :(