If you’re anyone like me who is interested to learn how other developers work and what their work environment looks like then this article might be interesting for you. Seeing Taylor Otwell and others sharing about their work inspired me and I decided to write about how I work too.
Office I’m a Jersey City, NJ based full-time software engineer at Buffer and work part-time on my side-project, Cronhub. Buffer is a fully remote company so I can work from anywhere I want. I prefer to work from home twice a week and the rest of the week I go to a co-working space with my friend Dan who also works at Buffer. I use Croissant to find a co-working space on-demand in New York City and hold a seat there. It’s very nice and convenient because I can experience new co-working spaces in the city every time. When I work from home I work from my desk most of the time. I don’t have a home office but I tried to make my desk (with my wife’s help) as cozy as possible considering the available space in my living room.
I have a Dell 27-inch monitor that I feel is the perfect size screen for me. I’m a lot more productive when I work on a bigger screen. Suddenly, everything becomes so much easier. When I’m in the co-working space I carry my Roost laptop stand with me so I can use it with my Apple keyboard and mouse. I don’t use fancy mechanical keyboards and feel quite comfortable with my mouse and keyboard.
Machine I use a 13-inch MacBook Pro, 3.1Ghz i7 with 16GB memory. Even though I love my laptop I think next time I’d go with a larger screen MacBook (probably 15-inch). I use iPhone XS as my primary phone and quite happy with everything. The Face ID is everything! 😅
Editor Okay, we got to everyone’s favorite topic, editors. For a long time, I’ve been a heavy Sublime user and promoter. However, I’ve switched to VS Code for 3 months now and can’t be happier. The primary factor that encouraged me to switch to VS Code was the awesome ecosystem that has been developed around this product. Switching from Sublime was quite smooth as I was able to keep all the Sublime shortcuts and didn’t have to learn new ones. I use Cmd + Shift + P and Cmd + P a lot to jump from one point to another.
I use Night Owl theme created by awesome Sarah Drasner and Dank Mono font in my editor. The font is not free but I think it was worth to pay. I can say that this has been the best color palette that I’ve ever used in any editor. My eyes enjoy it.
Terminal I use iTerm2 as my main terminal with oh-my-zsh’s default ZSH prompt. I have couple custom oh-my-zsh plugins and use iTerm2 with the “Arthur” color scheme:
Todo I’ve been a heavy Todoist user for more than 2 years now. I have a premium subscription and happy to pay more for this product. It has become an integral part of my work and how I manage my tasks and reminders. I use Todoist for personal tasks and work. You can create projects, set due dates on tasks and even have shared projects. I use Todoist on my Mac and iPhone.
I have experimented with so many to-do apps but I think Todoist was the only app that really stuck with me. Of course, I also keep a notebook with me for long notes and brain dumps. Most of the time I need to write things down in order to think and memorize. I use Midori notebook as my primary notebook.
Communication I don’t have a single app for communicating with my family and friends. I mostly use Messenger, WhatsApp, and iMessage. I find WhatsApp easier to use than iMessage. Some of my internet friends use Telegram so I’m there as well. Twitter is my favorite social network and I’ve made so many great connections on Twitter. One thing I’d like Twitter to improve is the DMs. I think they should focus more on improving the DM experience because it has a big potential. Or at least, that’s how I see it.
Music I have the Bose QC35 headphones and very happy with the purchase. It’s really a great headphone especially when you travel. I don’t have AirPods just yet but planning to buy one soon. I use Spotify for music and primarily listen to movie soundtracks, rock, house and 90’s rap:
My name is Tigran, I’m 29 and I’m the creator of Cronhub. It’s a side-project because I’m also a full-time remote engineer at Buffer.
For the past 5 months, I’ve been building Cronhub into a profitable side-business. Cronhub is a cron monitoring tool for developers. It monitors and alerts you if any of your scheduled jobs fail or run longer than expected.
In the past, I’ve shared an article on how I launched Cronhub while working full-time and today I’m writing about a topic that I had been wondering about for a long time after the launch. Finding the first customers is probably the hardest challenge for every product maker in early stages. This explains why so many people are curious how others managed to find their first customers and read their stories.
In this article, I want to share my story and experience of acquiring my first paid customers after launching my side-project. It’s been a fun and interesting journey full of joy and challenges. I hope I can shed some light on this process and inspire other developers to find their own path by reading my story.
Working on Cronhub
Having a full-time job and trying to build an online business on the side is challenging. The biggest challenge is being very organized with your time and not burning yourself out. Apart from my full-time job at Buffer I usually work on Cronhub 1-2 hours on weekdays and maybe 5-6 hours on the weekends.
I try to get 8-hours sleep each day otherwise I feel tired the next day which really hurts my productivity. Of course, there are some days when I feel down but I know it’s just temporary and I have to wait for the fog to lift.
Even though Cronhub is a side-business I pay a lot of attention to prioritize the tasks. I group all my tasks into two high-level buckets.
Tasks that will improve the product and make customers happy (product work)
Tasks that will bring more visitors by increasing the awareness of the site (marketing work)
There is also the other aspect that improves the activation of the product like creating and activating a Cronhub monitor but I keep it in the product bucket just for the sake of simplicity. The challenge here is finding the sweet spot where you balance the two buckets. Being an engineer I’m naturally more inclined to prioritize more product work but I’m deliberately practicing to overcome this bias.
Currently, I have 7-10 sign-ups daily. Most of the visitors come from my past blog post articles that are not necessarily my target audience. However, content marketing has been the only marketing channel that I’ve used with Cronhub. No cold emails or ads.
Here are some metrics that I thought could be interesting to share.
Product and Financial Metrics
Cronhub has around ~1100 signed up users
450 active monitors making around 130,000 pings daily. A monitor is active if it has received at least one ping from an external job or script (e.g. your daily database backup job, weekly digest email job)
Only in the last 3 weeks, Cronhub reported around 3000 cron job failures to our users. The failure can be either that job failed to run on schedule or ran longer than expected.
Net Revenue since the launch day is $710 (actual total gross revenue minus any fees, refunds, disputes)
Trial conversion rate 83% (I expect this number will go down eventually)
Monthly expenses, $57
My expenses haven’t changed since the launch day and I plan to keep it as low as possible.
Something I didn’t expect at all is seeing almost half of my customers choosing the yearly billing plan over monthly. I don’t know if I should make some conclusions here but I may if I see this pattern repeats when I gain more customers and data points.
One thing I’m very proud of but still plan to improve is Cronhub’s SEO score. It’s really cool to see a big chunk of my visitors coming from organic search especially for an early product like Cronhub. I think it’s a great validation for me to continue focusing on SEO and improving the organic growth.
Apart from the basic SEO techniques (like keywords, fast page load, etc) and writing content on Cronhub’s blog I haven’t done anything else. I’ll talk more about this a bit later.
Acquiring my first customers
When I launched Cronhub I could only dream about having 10 customers and now when I’m here it seems like I’ve so much yet to cover. Getting my first paid customer was very crucial for the product. I spent a couple of months building the MVP (minimal viable product) and I wanted to see the returns of my hard work. Also, I think having a product that people pay for is a great way to validate your idea and know that you’re onto something.
I was very lucky to get my first ever customer signing up for the “Developer ($7)” plan the next day after the launch. At that time I only had one paid plan on Cronhub but getting the Stripe notification of having a new customer was something special. It immediately boosted my confidence and pushed my motivation to the roof.
Later on, this customer switched to the business plan because he and his team needed more monitors. However, when he emailed me the “Business” plan was still on “Coming soon” phase but I told him that I’d upgrade him within the next couple of days and I did. I made it my top priority and had him on the business plan next week.
For the business plan, I had to build team member support from scratch but it was worth it because I knew I had to support teams on Cronhub anyway. Cronhub is primarily built for developer teams so team invitation and management support was a no-brainer. It was just a matter of time.
I manually upgraded the customer and offered a lifetime discount on the business plan. I’m always in touch with my first customer and he has been very helpful with providing valuable feedback.
So my first customer came from the Product Hunt launch, however, it took me 2 weeks to get two more customers and both within the same week. After the launch obviously the number of visitors went down so I had to think about ways to promote Cronhub. I really didn’t think for too long here and decided to do what I enjoy the most, write.
I really love writing. I think of writing as a way of meditating. It helps me to stay focused on one thing which is not always possible with my monkey brain. I knew I could write about my experience of building Cronhub as an online business which I’ve been doing ever since.
Writing helped me to grow my audience as well as market Cronhub. After starting to write I started to grow my Twitter follower as well. Below is the graph that illustrates the evolution of my Twitter followers after I started blogging regularly. I think you can see the breaking point!
When I decided to make content as my primary marketing channel I started a blog with a new subdomain blog.cronhub.io. With the new blog, my intention was to squeeze all the SEO benefits. Since I wanted to improve the SEO score to get more organic visitors I dedicated a week or so to make Cronhub more SEO optimized. There are many resources covering the basics which you can find on the web.
One example of how my site optimization and content writing helped on the SEO side is this screenshot from Google Analytics showing that almost 40% of my traffic on August 23-24 came from organic search. This percentage fluctuates between 20% – 40% every day. I think it’s great and I have to keep the spirit high. It would be great to know what the industry average is for SaaS products.
I publish all my articles on Cronhub’s blog first and then I republish them on Medium and Indie Hackers. It’s great that Indie Hackers allows setting a canonical URL for your articles which helps with SEO. One thing I do with my Medium articles is trying to get them published on popular publications such as freeCodeCamp. It’s a great exposure and opportunity to get your voice heard by a large audience. I highly recommend to give it a try. Here is a quick gif showing my post stats.
One downside of content marketing is that it’s very time consuming but it’s a long-term game. It’s like an investment you do now for a better future.
My hunch is that most of my current articles are read by many developers but the question is whether those developers are likely to show interest in cron jobs or not. As an example, If I had to write an article about Kubernetes Cron Jobs and how they work I’d expect that most of my readers know at least what cron jobs are. I want to narrow down the scope of my articles and target to more relevant developers. What I care most is not the number of visitors but the type of visitors. I have a couple of ideas and excited to see how they perform in the future.
After having three paying customers within the first month I was very pumped when I got my first yearly “Developer” plan customer in early May. It was around the time when I started to read and learn more about product pricing. I knew nothing about pricing but I was keen to learn.
I talked to product managers and people who understood SaaS pricing model better than I did (btw I wrote an entire article where I share all my learnings on pricing). Then, I changed my pricing table and added a new intermediate plan called “Startup”. It was in-between “Developer ($7)” and “Business ($49)” plans because I thought the pricing gap between these two plans were too high.
I changed the pricing and to my big surprise my next customer signed up for the yearly “Startup” plan. It felt really good. I felt like that soccer manager who brings a substitute player to the field and that player scores a goal. Then, I started to slowly acquire new customers until I got to the first sweet spot, 10 paying customers.
However, looking back it did take me almost 5 months until I got my first 10 customers. This is me being a solo founder working around 10-15 hours per week.
It’s been a slow journey and, of course, there are times when you don’t have a single new customer in the span of multiple weeks and you feel terrible with lack of motivation. But I know these things will pass and I’m excited more than ever to get to my 100 customers.
If I reflect on my past journey I can certainly say that there is no universal formula that one can use to succeed in this process. However, I believe that patience is the biggest player. You have to believe in yourself and be patient.
If I could make a list of my main learnings it would be this.
Focus on the core product and user experience in the beginning.
Do not spend too much time thinking about your pricing in your early days. Think of pricing as a feature that you can always iterate on. Start from the MVP.
Customer support is very important. Be a human, not a company. Be in touch with your customers and ask for feedback.
Decide what your primary marketing channel is and focus on it in the early days.
Share all the cool things you’re working on with your audience. People are genuinely interested in.
Ask for help and advice. People are generally nice and want you to succeed.
My next goal is to go from 10 to 100 customers. Today I asked for advice on Twitter and Joel Gascoigne replied with a great one.
I want to talk more to my customers and adjust my marketing strategy around the value that Cronhub provides to them. Apart from content marketing, I want to create more acquisition channels that have a higher activation rate. Finding a product market fit is my eventual goal. I hope I will get there soon.
As a side note, I’m very excited to share that Cronhub got accepted into YC’s Startup School Advisor track. It’s a 10-week long online course where you get exposed to a mentor and a great community. I’m excited to apply all my learnings on Cronhub and share my experience with you! Stay tuned for a new blog article.
Thanks for reading and let me know in the comments if you have questions for me. I’m happy to share more.
If you like my writings then you can subscribe to my personal mailing list so I can email you when I publish a new article like this one.
Creator of cronhub.io & software engineer at Buffer. Building a profitable side-business and sharing all my learnings. Previously at Twitter.
It was the winter of 2016 when I opened my phone and saw the job offer from Buffer. I remember I was in an Uber with my wife driving back home from the JFK airport. So many things have changed since then. I grew as a person and as an engineer. This article is a story where I openly share all my learnings and challenges I’ve experienced throughout my journey of working remotely as a software engineer.
My name is Tigran and I’m a software engineer at Buffer. I’m also the creator of Cronhub, a tool to help developers to monitor
cron jobs. In the past, I’ve created other other side-projects as well and written articles about my journey of building a side-project while having a full-time job.
I get a lot of questions on Twitter about my experience at Buffer and how it feels to work remotely. Most of the questions are about time management, work and day structure and the tools that I use daily to stay productive. Even though these are very good questions I’ve decided to step back a little bit and share my story from the beginning when and how I started my remote work. I hope to share all the good and challenging parts of my experience. I know remote work culture is rapidly growing across the world so I hope this will be a useful resource for beginners who’re considering to be remote.
I’ll be honest to tell you that I also wanted to write this blog post for myself to look back and reflect back. That’s why it may feel like I’m writing in my diary. I hope you don’t mind that style.
Starting a remote job
It’s interesting that I never thought about getting a remote job. It kind of didn’t matter at the time I was applying for new jobs in February 2016. I was living in Jersey City, NJ which is very close to Manhattan and I knew if I had a job in New York City the commute wouldn’t be an issue (especially with audiobooks).
However, at the time the top company on my list that I wanted to work for was Buffer which was and still is a fully remote company with employees spread across the world. I heard about and used Buffer before joining the team and read so much about their culture. I also really admired Joel Gascoigne (the founder of Buffer) and enjoyed reading his Buffer story and all the learnings he was sharing on his blog.
I applied for a backend engineer position at Buffer. Lucky for me this position was open at the time and it really matched my previous background working with backend technologies and services. I knew that Buffer had many applicants for the same position (if I’m not mistaken we had around 1500 applications for this position) so my hope was quite small. Only after couple weeks of me applying I received an email from Leo (the co-founder of Buffer who’s not with the company anymore) offering to chat. He wrote that he really liked my background and wanted to get to know me better in a call. I was beyond happy and excited for the opportunity and was really surprised because quite frankly I wasn’t expecting to hear back.
After my chat with Leo
, I started the interview process. Buffer makes sure that whoever joins the team is a great fit so apart from technical the interviews were also focused on the culture. When I joined Buffer, I had to go through a 45-days long boot camp. Boot camp is like a date where both of you take your time to figure out whether you’re a good fit for each other. While in a boot camp you’re considered a contractor until you become a full-time employee. Currently, we don’t have boot camp anymore.
As I said, I wasn’t necessarily looking for remote opportunities. It just so happened that I’ve become a remote worker because I really wanted to work at Buffer and I was excited to explore what remote work would offer.
Initial challenges of working remotely
Working remotely is very different from working in the office and I don’t think you fully grasp the difference until you actually start being remote. For someone like me who never worked in a remote environment the beginning wasn’t smooth and it came with challenges. Eventually, I got better at most of those things but it’s worth looking back now and reflect on my early days.
I can clearly remember my very first day at Buffer. I woke up, had a breakfast and coffee then started my day with this question: “So what’s now, what should I do?”. It was a valid question, really. There wasn’t any office that I had to go to and the way how I used to associate the start of my working day was the office. I felt confused and lonely for a moment.
In the office based environment, we rely so much on in-person communication that it feels really odd not to have that commodity anymore. The remote environment is the complete opposite because it’s primarily based on asynchronous communication. Actually, current remote workspaces are more of the combination of both synchronous and asynchronous communication and each one completes another. There are some tasks when synchronous communication is more time effective and later on you start learning when and what type of communication is better. Communication is still a big issue in remote teams but I think at Buffer we have found the good balance over the last years.
Getting back to my initial challenges, the biggest one I was facing was confusion over how the work is done and structured. When I joined Buffer I got assigned role and cultural buddies who were there for me to support me throughout my boot camp. Having them by my side was a huge help. I used every opportunity to ask questions and it helped me a lot understand the work process. In the beginning, I was mostly working from home in order to manage my time more efficiently plus I was nervous
of having video calls in coffee shops because of the noise and poor wifi signal. Wifi speed has become such a big part of my flow that I’ve bookmarked fast (a network speed measuring tool developed by Netflix) webpage on my browser and moved it to the right beginning of all bookmarks for easy access. Working from home really worked out for me in the beginning because I got a lot of things done with zero distractions but then eventually it made me feel more isolated.
Another challenge I was facing, in the beginning, was not being able to switch myself off from the work and constantly being online. I’d end up starting my day at 8am and signing off around 8-9pm. It didn’t last long but obviously working long hours was a problem. You have to be very strict with your working hours otherwise mental exhaustion can easily take over. You don’t want that. You want to set your working hours and stick to them. Of course, you can be flexible when and how you work depending on your lifestyle but time management is key. Think about what time of the day you’re most productive and construct your day accordingly. For instance, I’m a morning person so I do the most important tasks first thing in the morning. With no destruction and 2-3 hours focus work, I can get a lot of things done. I try to schedule my calls in the afternoon when my mental energy is not too high but I can still concentrate and focus on the conversation.
I’ll continue talking about my work routine a bit later. In the meantime, let’s talk about how I’ve become better at remote work after my initial challenges.
Getting better at remote work
The first couple of months of working remotely were the most challenging for me. Working at Buffer was great and I think because I worked for Buffer I’ve found a way to overcome these challenges. With the help and advice of my teammates and the learnings from my experience over time, I felt I’ve become better at working remote. I felt I was more productive and found my place. Now when I look back I think there were a couple things that really contributed to that success and realization.
Two months after joining Buffer my colleague Dan Farrelly and I decided to find a co-working space in NYC where both of us could commute a few times a week. I was super pumped and lucky to have a co-worker based in the same area as I was. Dan, who is now the director of engineering at Buffer, has become my best pal whose advice and help really shaped me as a developer and remote worker. I found a friend and co-worker who also worked remotely and had enough context in the remote environment to understand my challenges. We started to co-work couple times a week, have lunch together and discuss a variety of topics including our work at Buffer. As of now, we co-work 2-3 times a week in New York City and the rest of the week we work from home.
Finding someone who you can work with is a great way to stay social. One of the other things that I’ve tried and it was very useful was attending meetups in NYC on the topics that interested me. I met like-minded people who I could find common things to connect about. Online communities can be helpful too and there are many remote work-based communities you can be part of.
I started to better manage my time. Every day I dedicated time to prioritize my next day’s tasks by setting specific goals. I usually set 3-4 tasks for a day because I usually don’t go beyond that number. Prioritization really helped me with time management and it also made me more focused on things that mattered. The tricky part of remote work is that you fully control your time and you have to be very cautious how and what you spend your time on. Of course, distractions can happen but finding ways to improve your focus is such a key element of a productive remote work.
We use Slack at Buffer and I heard about Slack in the past and knew it was very popular among tech companies. I think it is a great tool and it has many benefits for the workplace including bringing the team together. However, it’s focused on synchronous communication. For some remote teams like Buffer asynchronous communication is very important and it has become part of our DNA and culture. We are very mindful of our teammates’ time so we want to structure our communication in a way that at least some portion of it can be handled asynchronously.
Another reason why we are inclined to communicate asynchronously is the time zone difference between our teammates. We are spread all around the world and it’s not always possible to jump on a call or get an immediate answer to your direct messages.
Buffer is also very supportive of each team member’s lifestyle and we respect the working hours of everyone on the team. Prioritizing my time better helped me to get better at async communication. I’ve started to rely more on tools that enable asynchronous communication like email or Dropbox Paper.
I started to pay attention to mental health as a top priority. I work better when I’m less stressed. I’m lucky that Buffer is an amazing place that supports mental health for every bit of it. I started to work out in the mornings, play soccer and track my working hours which drastically improved my mood and motivation. I stopped working late hours and tried to get a good 8 hours sleep every night.
I finally started to take advantage of my remote work lifestyle. I started to travel more, going to Buffer retreats and visiting my family in Armenia for month long trips. It’s really incredible to have the flexibility to spend a month with my family and friends in Armenia. Being able to work from anywhere I think it’s the most awesome advantage of remote work. Since the beginning of the year, I’ve traveled to Canada, Mexico, Bali, Singapore and flying to Armenia in a month. We are planning to visit more destinations in the future.
My typical workday
I have people asking me this question a lot on Twitter so I’ve decided to dedicate a separate section to write about what my typical workday looks like.
I wake up at 7:05am every day. I have an alarm setup but rarely need it. My body has its own alarm that is quite precise. I wake up and the first thing I do is making my morning coffee and have it with the pre-workout meal. In the summers, I’m usually having an espresso with an ice cube which makes the coffee more refreshing. At 8:10am I’m at the gym to work out. I’ve been doing weight exercises for a year now by strictly trying to follow Bigger Leaner Stronger: The Simple Science of Building the Ultimate Male Body program to gain muscle and lose fat. It’s been working out great for me and I see the difference in my body and general health. I highly recommend this book if you’re unsure what workout program you should follow. It’s a great book for beginners in particular. I’m tracking my workouts using Strong and very recently hit my 100th workout.
I spend an hour in the gym and right after it, I try to have my protein-rich breakfast. Usually, it consists of eggs, cottage cheese and a piece of whole wheat bread. After my breakfast, I’m getting ready to start my working day. I usually ping Dan to decide where we want to work from that day. We use Croissant to find and book a co-working space. It’s a great app and has many spaces available in New York City. We usually stick to the ones in the Financial District because it’s relatively close to both of us. It takes 12-15 minutes door to door for me to get there. I’m in the co-working space around 10-10:30.
I’m done with work around 6:30pm on a typical day. Couple times a week I have evening soccer games so if that’s the case I try to be home a bit early to have a light dinner before my game. Playing soccer is probably my most favorite activity in the universe. I’m a huge soccer fan although my wife doesn’t really like the idea of me paying $140 for authentic soccer jerseys. However, last year she surprised me by arranging a meeting with Henrik Mkhitaryan in London who is my favorite player.
Unless I’m mentally very tired I spend most of my evenings working on Cronhub and trying to grow it. I’ve written a couple blog posts in the past about Cronhub and how I’m trying to make it into an online business. I’m very lucky that my wife is very supportive of this and she is rooting for me. I’m a big believer of side-income and that’s why I try to spend at least 2 hours every day to work on my side-project. If I’m very tired I just crush on the couch and watch a Netflix show with my wife. In the weekends I’m mostly trying to rest and do something with my wife and friends. There are weekends where I work on Cronhub but not that often. I know how critical the rest is.
What tools we use and rely on plays a huge role in our productivity and work life. At Buffer we are generally open-minded to experiment with different tools that we think could benefit the team.
Here are some of the tools that we use daily at Buffer.
G Suite – From the G Suite family we use Gmail and Google Calendar. We use emails a lot and that’s why I have auto filtering and labeling setup so I can easily go over my inbox. Setting up filters and labels is not that fun but it’s worth investing your time just once and forget about it later on.
Slack – We use Slack for sync communication and direct messages. We have a general channel, engineering, etc. I like Slack and I think there are situations when it’s hugely beneficial.
Zoom – We use Zoom for video calls. We are so dependent on Zoom and it’s such a great tool to bring the entire team together. It handles quite well the calls with many team members which happens in our all hands.
Dropbox Paper – Probably one of my most favorite tools. Even now I’m using it to write the draft of this blog post. We use Paper for collaboration and note-taking. It’s a big part of our asynchronous communication.
Discourse – We use discourse for announcements, promotions or sharing general learnings in the team. I enjoy using discourse and I find it very intuitive to navigate.
Apart from these tools I have my own tools that help me to be more productive. I’m a happy Todoist user where I log all my daily tasks and check them when they’re done. I track my working hours with Rescue Time. It’s a great tool that helps me to understand how I spend the most of my time and where. It also monitors the use of social media that I’m actively trying to reduce. In a remote team, you usually end up creating and sharing screenshots or screencasts to show something to your teammates. We use CloudApp for this purpose and it’s so worth it. Highly recommend.
Finding a remote job
If you’re looking for your first remote job then this short section will probably be useful for you. Remote work is quite trendy nowadays and many companies introduce remote work as an option for their employees. You can either work in a fully-remote company or a company that has an office but has also remote teammates. There are also the freelancers who can be considered as remote workers too but it’s a bit different I think. My experience is only based on working in a fully-remote company that has no office.
If you’re non-remote right now but considering to switch to remote so you can travel or spend mo
re time with your family then the good news is, it’s getting easier to find remote opportunities because the field is growing and companies are starting to realize the benefits of going remote. Remote companies have the big advantage of hiring talented people from the large pool of candidates because the location is not important anymore. I know a couple of companies apart from Buffer that is fully remote Automattic, GitLab, InVision, Doist, Zapier.
You can always go to
the career pages of these companies and see if they have any open job opportunities. There is also another great resource you might consider. The one that I like is
Remotive is a community that helps you to find a remote job. If you already have a remote job then you can connect with other remote workers, get tips or start a discussion on any topic. Another great website that is more focused on helping you to find a remote job is Remote OK.
Remote vs Non-remote
Before joining Buffer and working in a fully remote company I worked for office-based companies. While I was doing my masters at RIT I interned at PTC for 7 months and 3 months at Twitter. After the school, I joined YCharts and stayed there for a year. I’ve experienced both working remotely and working in the office. I think both workspaces have tradeoffs.
In a remote work you’re not tied to a location so you can potentially live in a cheap place and earn enough to have a good life. In fact, I have a couple of Twitter friends who’re currently living in Bali and working for a remote company or trying to start their own thing. Their expenses are quite low compared to mine who lives in a New York City area. A couple of months ago when I was in a co-working space in Bali I saw many digital nomads living and working from Bali. Nomading feels like a movement now.
When you work remotely you also have the option to choose your working hours. So if you have a family you can spend more time with them
by work from home. However, you have to be a self-motivated person and eager to stay focused most of the time. Loneliness can be an issue too so finding different ways for you stay social can be helpful. Of course, it also depends on your personality
In an office-based job, you’re tied to a specific location. You have to commute to your work which sometimes can take a lot of time. I also think developing personal relationships with your co-workers is a bit easier in-person when you all are in the same space. At Buffer
, we have annual retreats where the entire team gets together for a week. It’s probably one of my favorite times of the year because I get to see my co-workers and spend time with them. It makes such a big difference because it brings us together and helps us to develop better relationships with our co-workers.
To summarize, working remotely as a developer for almost 3 years has been an incredible journey for me. Years full of professional learning, travel, connections and new experiences. This reflection is solely based on my own experience of working at Buffer so it can differ from someone else working remotely.
I often get asked but I don’t have the answer yet whether I’ll ever go back to be non-remote. It’s hard for me to tell because it really depends on the opportunity. I like the lifestyle and freedom I have but it can change in the future. Right now, I’m focused on my work at Buffer and growing Cronhub as a side-business. My eventual goal is to become financially independent so I can spend my mental energy on things that I deeply care about. It has probably become the north star that guides me forward and gives motivation. I see the path that I can take to achieve that goal and I’m doing my best.
If you’re new to remote work or looking for one then feel free to reach out to me with your questions. I’m always available to help and share more.
If you like my writings then you may want to subscribe to my personal newsletter so I’ll email you when I write new articles. I plan to do it at least every month. Thanks for reading.
If you asked me if I could ever write an article about pricing a couple of months ago it would probably make me laugh. I didn’t know anything about product pricing even though I’ve launched my first SaaS project. The way I priced my product was solely relying on my own intuition as well as looking how other similar SaaS products priced their services. I think this is what most beginners do.
Why on earth then write an article if you’re not an expert on pricing? Because I’ve come to realize that it’s totally okay to write about topics you’re not expert on. Chris Coyier’s tweet “Write the article you wish you found when you googled something” inspired me to start writing about things I wish I could find on google. I started to use blogging as an excuse to learn a specific topic. This article is a fruit of that inspiration and I’m happy to share it with you all.
There aren’t many articles on side-projects pricing even though the number of revenue-generating side-projects is growing. If you go to Indie Hackers you can see many of them there and many makers in the community wonder and ask questions about pricing as well.
In this article, I’ve summarized everything I learned about side-project pricing. For the last two months or so I’ve started to read about pricing and talk to people who are knowledgeable about pricing. It really helped me to understand the basics needed to create a more successful pricing model for a SaaS project. In this article, I’m using Cronhub (my side-project) as an example to better explain my view and thinking process because I believe it’s easier to digest new information using an example.
All my learnings here apply to SaaS products but I think other types of businesses can benefit from them too.
Monetizing your project from the day 1 is very important. You can think of the “monetization” as a feature that you want your product to have. This feature significantly increases the success chances of your product. Usually, you build features for your customers but this one is for you, to keep you more motivated to work on your project.
Your motivation and persistence are the key drivers to move your project forward. If you value something it keeps your motivation high. What’s the easiest way to know whether your project is valuable? Asking people to pay for it. In my opinion, if you can find 10 people paying for your project then you can find 100, 1000 and more. Finding the first customers are the hardest.
Because finding the first customers is hard it’s important to set up the right pricing model in the beginning. Pricing is a living feature and as any other feature, it requires multiple iterations until you get it right. It’s totally okay to make mistakes in the beginning and in fact, for Cronhub I’m still not sure whether I’ve got it right or not. However, I’m open to change it if need be and that’s what matters.
If your intention is to build a business from your side-project then you should charge for your project. It’s hard and more often demotivating to work for free. You value your time and others should do, too.
Since I’m not an expert in this field I can’t give you very technical answers to pricing strategies. However, one thing I can do is to explain these strategies in a more human way with simple words.
Maybe that’s even better for you? 🙂 Good. Let’s get to it.
The primary goal of the pricing strategy is to maximize your product revenue. According to the book that I’ve read “The anatomy of SaaS pricing strategy” (which a great book btw), there are three pricing strategies for SaaS products.
Cost-Plus Pricing This is the most basic pricing model you can think of because it really makes sense. First, you calculate everything that costs money to your project and then
add a healthy margin on top of it. The margin is your profit and it represents the value that you give to your customers.
Let’s take Cronhub as an example. Cronhub is a
cron job (or any scheduled task) monitoring tool. Monitors cost me money because they send emails and SMS to my users. Sending emails and SMS is costly for my business. Having more monitors will increase my cost and that’s why I priced Cronhub by the number of monitors. If you want more monitors you should pay more.
I think most first-time side-project builders take this approach because it’s simple and it covers the costs. The challenge with this pricing strategy is the unpredictability of the future. If your costs unexpectedly go up in the future your profit margin will cut and you will have to increase your prices.
Competitor-Based Pricing As the name implies this pricing strategy is influenced by your competitors. When you don’t know the initial value of your product you usually turn to your competitors. You check their pricing tables so you can come up with yours. Well, I have done it for Cronhub too.
If you’re launching a product in a new industry it makes sense to check competitor pricing because you don’t want to go too high or too low. We’re always afraid of losing customers because of the big price difference from competitors.
This pricing strategy is simple and less prone to be wrong. You can probably spend an hour or so researching competitors and come up with a pricing table that is similar to your competitors. This way your future customers won’t think that your product is too expensive or too cheap. The one downside I see for this model is that you don’t want to be guided by your competitors from day one. You want your product to have its own personality and it should be reflected in the pricing as well. Use competitor pricing as an inspiration and benchmark but not your guiding strategy. For me, I see this strategy mostly used in combination with other pricing models.
Value-based pricing This strategy is also called customer-based strategy and is solely based on your customer surveys and research. You want to know how much your customers are willing to pay for your product and the only way to do so is to go and talk to them. Most companies use in-product surveys to collect this data.
Many other benefits come with this strategy too. You get to know your customers and their needs which helps you to build the best product. I think following this strategy you’re most likely to come up with a better pricing table. However, this model can only be applied after some initial iterations when you have a decent customer base. That’s why I believe that this model should be used as part of the last pricing iterations on your pricing table. It doesn’t mean that you should not talk to your customers from early days. Just set a goal for yourself that you eventually want to use this strategy to decide your pricing table.
You may want to re-apply this strategy every so often because your customer base is changing and the market needs do, too.
Break down your customers into groups
The reason I wanted to write about customer groups is that I strongly believe that breaking down your user base into groups is not only important to build a better product but also to model your pricing. When you start thinking about pricing you naturally measure it with only one dimension using just a single variable (like I used only the monitor count as a pricing measure for Cronhub).
However, you want to add another dimension based on your customer groups. There is a term called “Pricing Axes” which I first heard from Joel Gascoigne in our company retreat this year in Singapore. These axes represent variables that you can use to better model your pricing. For instance, Cronhub has 2 pricing axes now after launching the team plan. The first ax is the number of monitors and the second is based on the team member count.
Breaking down my customers into groups helped me to come up with the second ax for Cronhub. I have divided my potential customers into two groups, solo developers, and developer teams. It naturally makes sense that there should be different pricing for each of these groups because their needs are different. Following this strategy, I’ve created two pricing plans for the team depending on the count of the team members they need.
Of course, you can add more axes along the way and it depends on your product. I think keeping your pricing axes around 2-3 makes sense at least in the beginning. Adding more variables may confuse your users and you don’t want that.
Applying the strategies on Cronhub
I want to also talk about how I’ve applied above-mentioned pricing strategies for Cronhub and the pricing challenges I’ve faced when starting Cronhub.
Cronhub is a product for developers. I knew that developer market is not an easy one to be in but it didn’t stop me starting something I’m very passionate about. I really enjoy hanging with developers and getting to know them better. For me, what mattered most is to launch a product that will serve this market.
Being a developer I know how much developers love to use free tools. However, they’re also prone to pay for a product that provides significant value to their flow and productivity. I want Cronhub to be one of these tools. I launched Cronhub with only two plans, “Free” and “Developer ($7/month)”. I wanted to see whether this is something other developers will pay for or not.
My very first pricing model was mostly a symbolic strategy to validate my idea. I didn’t spend much time thinking about the pricing plan and followed Cost-Plus pricing strategy to use the monitor count as a divider between free and the paid plan. In the first month, I’ve got couple paid customers which made me revisit my pricing. That’s when I’ve decided to invest a little bit of time to learn about this topic.
After two months of reading and seeking advice from product people I’ve come up with these key learnings that I’ve applied on Cronhub.
Don’t give up too many things in the free plan We tend to give up too much in the free plan especially in the beginning. It’s quite possible that your product doesn’t offer any free plan however for Cronhub I wanted to use this channel as a way to acquire customers. Limit the free plan to the minimum.
Know your customer groups Knowing your customers is important to understand how much they can afford to pay for your product. Cronhub’s free and developer plans are intended only for solo developers who have projects on the side. I have two team plans “Startup $19/month” and “Business $49/month” and they are intended for engineering teams. Engineering teams should collaborate together so the team support is necessary. Team sizes are different and that’s why I’ve priced these plans by the number of team members.
Think about your conversion flow Picturing the customer conversion flow in your head is really helpful in understanding how pricing may work and that’s why I’ve decided to offer a free plan. The way I imagine the flow is a developer signing up for the free plan to use it for their personal projects. If he/she likes my product very much the chances are high that he/she will also promote my product in the company that he/she works at. It’s the word-of-mouth effect. Now someone from her company signs up to try the team plan and there you have your potential lead who is very likely to become a customer.
Your pricing is probably too cheap Don’t be afraid to raise your prices. We tend to undervalue our product because we are afraid that no-one will pay if it’s expensive. This is true especially for people who don’t have experience with pricing. Unfortunately, pricing your project very cheap may discredit the value your product provides. It can make people question the quality of your product. That’s why you want to find the sweet spot when it’s not cheap and also not expensive.
Pricing will affect your long-term productivity If you’re a single person team then you probably do the product support as well. Higher paying customers tend to create fewer support requests compared to the customers who have signed up for the lowest pricing plan. Think about your time and how you want to spend it. If you’re planning to stay a one-person team then this will make a huge difference. For Cronhub, eventually, I’m thinking to have only 2 plans, free and business plan. The free plan will be for developers and the business plan for small and medium-sized engineering teams. Instead of having many low paying customers (and spending many hours answering support questions) I would prefer having a small number of high paying customers (and enjoy building a product).
Thank you very much for your time. I hope you enjoyed reading this article and learned a little bit about side-project pricing. Writing is what I enjoy doing most after programming and I hope to write more articles in the future. If you don’t want to miss any of my writings then you should follow me on Twitter. Feel free to say hi to me or ask questions below!
Finally, If you’re a developer or part of a developer team that uses
cron jobs you can try Cronhub for free to monitor all your
cron jobs in a beautiful dashboard.
This is a short blog post to transparently share all Cronhub numbers for the last 30 days[April 20, 2018 – May 20, 2018]. It has been exactly 2 months since I’ve officially launched Cronhub on Product Hunt. In the last two months, I’ve learned a lot about what it takes to build a side-business and I’ve pledged myself to always be open about it and share all my learnings. I’ve already shared the first-month report on Indie Hackers and the reaction from all of you was incredible. I know these reports inspire many indie hackers to start their own projects and as long as it’s useful I’ll continue writing my monthly reports and share my learnings and the challenges I face.
Now let’s get to the main topic where I share the metrics that I believe are important for any online side-business.
The main accomplishments
Cronhub has become profitable
Last month Cronhub hit the first milestone that I’ve set for myself from the day of the launch. My side-project is now a profitable side-business. This means that monthly recurring revenue covers the cost of all the monthly expenses that are required to maintain Cronhub.
Launched“Business” plan I’ve launched the“Business”($49/m) plan with team members support. This means that I can start targeting businesses and developer teams so they can collaborate on Cronhub to monitor their cron jobs. Along with this plan, I’ve launched the“Startup”($19/m) plan for small teams and startups.
First“Business” customer One of my “Developer” plan customers converted to“Business”. Now with the team member support, his team can collaborate on a shared dashboard and monitor more cron jobs.
First yearly customer I’ve changed the pricing this month and before making the change Cronhub had only 2 plans,“Free” and“Developer”($7/m). Last month, I had the first customer upgrading to the yearly plan and it was a such a great feeling to receive that Stripe notification.
Awareness and acquisition(~5200 sessions)
In the last month, my primary goal was to launch“Business” plan with team members support so I’ve dedicated the most of my time on building this feature. I knew that the number of visitors was going to stay the same or decline because I didn’t write any articles or made an extra effort to market Cronhub. However, the next month I’ll pause a big feature development and instead focus on marketing my product as well as talking to my current users and customers.
Here is the GA chart that shows the sessions over the last month.
I’ve aggregated all the visitors by the top channels.
The number of the visitors declined compared to the previous month because last month the majority of the visitors came from the PH launch. However, there is one metric that I’m very happy and a little bit proud of, it’s“Organic Search”. It’s growing quite well compared to the previous month and I expect this number go up in the next months as long as I continue writing.
I’ve not done any SEO hacks or anything jut writing articles about Cronhub and sharing on different publishing platforms. I also have a blog where I cross-publish my articles. For instance, this article has a canonical URL to a blog post published on my blog. it’s really great that IH allows setting a canonical URL to an article. This means that all the SEO benefits from this article go to my domain blog which promotes the credibility of my domain.
Cronhub has 650 signed up users and in the last past month, I’ve added only 150 new users. I’m not very proud of this number but as I’ve mentioned in my last report I never expect this number to be very high. Cronhub is a very niche product and I think for niche products having a high number of signups is very rare or at least in the beginning. I’m working to improve the number of sign-ups by bringing more visitors and I’ll talk more about in my future blog posts.
Currently, there are 217 active monitors on Cronhub. A monitor is active if it has received at least one ping. All these monitors have sent around 5300 notification through various notification channels(Email, Slack, and SMS).
Revenue($67 MRR and 4 customers)
Cronhub has 4 paying customers and the monthly recurring revenue is $67.43. This revenue covers all my expenses and it’s already great! Of course, this is only the beginning and I’ve set new goals to achieve. I have a full-time job at Buffer so I’m totally okay to have a very slow but incremental growth. As long as the numbers grow and Cronhub keeps providing value to my customers I don’t really care how fast it grows. I’m sure it would have been different if I didn’t love my current job at Buffer. I see Cronhub as a side-business and I have no plans to quit my current job as of now.
All my current expenses haven’t changed and it sums up to $57. I’ll try to keep it low and here is the breakdown of the services I use for Cronhub.
The biggest challenge for me is acquiring more customers. I don’t do any sales or cold emails and I solely rely on my marketing efforts. I should probably start thinking about adding different tunnels for my free users to upgrade as well. Focusing on my current free users is key and can be a great strategy to bring more customers. I’m still figuring this out.
There are also some questions I keep asking myself over and over again:
Who are my ideal customers?
How can I find them?
Does my product justifies the cost of the value it provides? If no, how can I improve the product? What am I missing?
For the next month, I have two main goals along with some minor product improvements. The first goal is to publish the article that I’ve drafted about side-project pricing. I know there aren’t many articles about how to price a side-project so I’ve decided to write one even though I’m not an expert at all(Follow me on twitter if you want to know when I publish it). The next goal is to start working on a new Cronhub feature which will allow users to monitor the“processing time” of cron jobs and set alerts on top of it.
This is a short blog post to transparently share Cronhub’s metrics in the first month after the launch. I’ve launched Cronhub on March 20, 2018 on Product Hunt and the reaction of people were mostly positive. Every month I’m planning to write a quick report and share it with everyone. My plan is to build Cronhub openly and I’ve already shared two personal Indie Hacker articles on Cronhub in the past month. With these articles and report, I want to provide insights on what it takes to build a profitable side-business from scratch. I also felt that it inspired a lot of indie developers to start their own projects and be more open what they work on.
This is my first report so please take this with a pinch of salt. There might be some metrics I’ve completely missed so please add the metric you would like to see in the comments below.
Now let’s get to the metrics for March 20, 2018 – April 20, 2018.
Awareness & Acquisition (10,807 sessions)
These marketing metrics measure the reach to the potential customers and how they convert to visitors. Each visitor to Cronhub site is a session. I primarily use content marketing to expand awareness of Cronhub and acquire new visitors who I think may turn to potential customers. My market is developers. In the past month, I’ve written two Indie Hackers articles and republished them on a Medium publication. I’ve also launched Cronhub on Product Hunt which brought a lot of visitors to the site.
The reason why referral has the biggest chunk of the pie is the PH launch which brought almost 30% of all traffic in the last month. After the launch the direct and organic search traffic started to take off which is promising.
If we break down the referral traffic we can see that publishing my articles on Indie Hackers and republishing them on Medium wasn’t a bad idea. It drove a good amount of visitors to the site. I should also keep using Twitter to provide updates and promote Cronhub.
Activation (500 sign ups)
This product metric measures how many of the visitors acquired by marketing channels sign up for the product. Cronhub has 500 signed up users. As I said in the past Cronhub is a very niche product so I never expect this number to be very high. However, I want quality users who will actively use Cronhub and get a value from it and eventually turn to customers.
Active Monitors (145)
Currently, there are 145 active monitors on Cronhub. A monitor is active if it has received at least one ping. These active monitors have sent around 2600 notifications so far through different notification channels.
Cronhub has 3 paying customers on the“Developer” $7 plan. Current MRR is $20.
Digital Ocean to host Cronhub site as well as the blog. I’m planning to move Cronhub to Kubernetes soon so I think that will also save the hosting costs. – $19
Laravel Forge makes it easy to host Laravel Applications. Once I’m on Kubernetes I won’t need Forge. – $19
I think I should work on the better onboarding process for new users. Most users sign up but they don’t integrate their cronjobs with Cronhub monitors. I should make the integration part seamless. I’m working on this.
I’m working on a new Business/Team plan that will allow teams to use Cronhub. I may also adjust the pricing model of Cronhub. However, I know it may take couple iterations until I get it right.
If you’re a developer or part of a developer team that uses cronjobs you can try Cronhub for free. Use coupon “indiehackers” to get 20% discount if you upgrade to “Developer” plan.
Two weeks after the launch I have 1 paid user, about 450 sign-ups and 125 active cronjob monitors on Cronhub. I consider the monitor active if it has at least one ping. My MRR is $7 and I currently spend around $40 per month to cover all Cronhub expenses. I expect the expense number to grow a little bit in the future.
Now, that we know where I stand I’ll go ahead and share what comes next for Cronhub and how I plan to acquire more paid users in the next 100 days.
What’s my goal?
My goal is to find a product market fit. What does it mean to me? It means to acquire at least 10 paid customers on “Developer” plan and one customer on the “Team” plan (I’ll be launching the team plan next month). These numbers are random but also important. The reason I’m so focused on these numbers is that I believe nothing endorses the value of the product more than paid users. If I have 10-15 paid customers I can tell myself that I’ve found or I’m very close to product-market fit.
With my goal and these numbers, I want to measure the success of the decisions I make around Cronhub. My product decision domain is very broad and it’s not tied only to what features I should build next. I also ask myself how I should market Cronhub or who my ideal customer is. If you ask me now I won’t know the exact answer. Individual engineers and the engineering teams? Probably, but I have to be certain. I want to eventually find the niche market that Cronhub belongs to.
If you’re an engineer like me you know that building is most likely the easiest part and what comes next is the hardest. I’m so pumped to challenge myself, though.
Now that I have set my goal I want to talk about the steps I’ll take to achieve it. Of course, as any other goal, it’s possible that I won’t achieve it. However, what drives me is really the process of getting there. During the next 100 days, I’ll learn important lessons from all of the good and bad decisions I make and I promised myself I’d write them down in my decision journal. Decision journal helps me to reflect on my decisions so I can become a better decision maker in the future.
I’m a product engineer and this step is probably the one I’m most qualified for. Spending time to build new features or even fixing bugs is the most fun activity compared to other things I have to do. However, I know it’s a myth that if you build it people will come. I don’t believe in that. Most engineers tend to measure their productivity based on how much they ship. I’m afraid I’m not an exception here, however, I try to change the way how I think about my productivity. It doesn’t always have to be materialistic. Sometimes the time you spend to think about a particular product feature is the most well-spent time.
Before jumping to the code to build a new feature I try to spend enough time to answer the following questions.
Is this feature really needed?
If the answer is yes then I ask another question. Is this the most important thing I should be working/building right now?
Usually, these two questions are enough to decide whether this feature will make it or not. Prioritizing and time management are likely the most important skills for solo-developers. As a single founder or maker, we don’t have too many resources to rely on so we do everything by ourselves. That’s where the time and prioritizing come to play.
Most of the Cronhub product ideas come from the user feedback as well as my own intuition. It’s a mix of these two. For user feedback, I have a dedicated Dropbox Paperwhere I collect all the Cronhub feedback I’ve received from different people and users. This is how I’ve organized it so far.
I keep most of my ideas in the Trello Backlog column and then prioritize them into product cycles. At Buffer, we use 6-week product cycles and I find them very valuable. As a team, we get a lot of things done within 6 weeks. I’ve decided to do something very similar with Cronhub as well. The difference is that my cycles are a month long and I have one week in between cycles to prioritize the most important tasks for the next cycle.
If a single feature request comes up many times it gets higher attention from me. For instance, “Webhook Integration” was one of them and I shipped it yesterday. Every feature is broken down into very small tasks. If I need to spend more than a day on a single task then this task is not small enough. Keeping my tasks smaller has been key to see a continuous progress.
For the next 100 days, I plan to finish 3 product cycles. I hope after 3 months the improvements on Cronhub will be very visible. What features do I have in mind for the next 3 cycles?
I want to launch the new “Team” plan. It will be $49 per month and it will include unlimited team members with up to 100 monitors. I can start targeting teams too when I have this plan available. This plan will most likely have a “Free Trial”. I know my ideal customers are teams and not individual developers. Also, I think selling a product to businesses is a lot easier than to individual consumers.
I want to improve the weekly report I send to all Cronhub users. Weekly reports are super important and I want to make it more valuable to my users.
Product improvements and better documentation. As a developer, I really appreciate the importance of a well-documented product. I envision Cronhub docs to also include educational materials.
I think all these will keep me busy for the next couple months considering that I also have a full-time job that I love!
I know I have to market Cronhub no questions asked. However, I’m not sure how I should market it and what the best marketing strategy is for Cronhub. I’ve read Gabriel Weinberg’s “The 19 Channels You Can Use to Get Traction” article (which is great btw) and it helped me to find a temporary answer.
I want to focus on the marketing channel I personally enjoy and my working competitors dismiss.
I think that would be content marketing. None of my competitors are focused on content marketing and I personally enjoy writing articles and educational materials. After all, I come from a family of teachers.
But first, I have to define what content marketing means for Cronhub. Most of my users are developers so I roughly know that my target audiences are developers and developer teams. I should write content that acquires more developer visitors. I’ve created the following flow to better visualize my marketing strategy.
My marketing goal is to bring visitors that are more likely to convert to paid customers. Since I don’t know who exactly those potential customers are I want to bring more visitors so I can put the conversions into buckets by visitor types. This way I can differentiate the type of visitors that convert and that will probably be my niche target audience.
When I have a better idea of my target audience I can research to find out what really interests them. I’ll write blogs posts and educational articles on the topics that interest them.
But for now, I’m going to focus on the broad developer market and write content for that audience. This article is part of that strategy. Since I’m a developer it’s not hard for me to guess what type of content will attract other developers. Building a product for the market that you’re part of is really invaluable. I built Cronhub to scratch my own itch and because I believed that there have to be other developers facing the same problem. I hope I’m right.
Another reason why I think content marketing is a better fit for Cronhub is that I strongly believe that investing in a quality content now will pay off in the long run especially for SEO. I’ll probably write a different article just about SEO but in a nutshell, I’m planning to get better at the SEO game by hosting my own blog on Cronhub and constantly producing quality content for developers.
Apart from content marketing I also want to touch a quick hack I’ve done on Twitter to bring more visitors to Cronhub. Most of my Twitter followers are tech people so it fits well to use my existing audience as well.
I love Twitter and I use it to occasionally tweet updates on Cronhub. Some of my past tweets got high attention very recently. Those tweets most often earn profile clicks. Knowing that I’ve intentionally added a direct cronhub.io link to my Twitter profile so people checking out my profile are more likely to click on that link. Believe it or not, it really worked. The days when I have high tweet engagement I have relatively more visitors to Cronhub. It has become an essential part of my social media marketing plus I really enjoy connecting with my followers.
One example is my most recent tweet that earned high impressions thus many profile clicks and checking GA I saw I had more visitors for that day.
Now that I’ve shared my goal and strategies with you the next step for me is to accomplish them. And this has to be without burning myself out or exhaustion. Since I have a full-time job I plan to work 1-2 hours every day on Cronhub. Rest is very important to me so spending long nights or working long hours on the weekends is not an option.
I’ll be dividing my time between product and content marketing. I’m so excited for my journey and can’t wait to share more in the future. Expect more articles like this from me.
Thank you very much for reading. I hope you enjoyed reading my story and learned at least one thing from it. Even if you didn’t maybe this inspired you.
If you’re building a product and this story resonates with you I’d love to hear from you. What have you done for the first 100 days after the launch of your product? Please feel free to comment with your questions. You can reach out to me on Twitter or email me.
If you’re a developer or part of a developer team that uses cronjobs you can try Cronhub for free. Use coupon “indiehackers” to get 20% discount if you upgrade to “Developer” plan.
This is my personal story of how I shipped my very first SaaS side-project while working full-time at Buffer. The goal of this article is to inspire you. If you’re someone like me who has a full-time job and wants to build a profitable side-business as a source of income then this story may resonate with you.
With this article, I want to show how I didn’t “hustle” or overwork and was still able to ship a real SaaS product.
I’m a web developer and I’m very lucky that apart from playing soccer in my free time I also enjoy coding and building web projects for fun. Most recently, I’ve created Booknshelf which helps many people to organize their books online. While working full-time has a big impact on my engineering growth some of the developer skills I’ve acquired from working on my personal projects.
It was only last year when I started to think about having a different source of income apart from my full-time job. The idea of being dependent on a single paycheck is a bit scary. I knew I have the skills and passion to figure something out. I decided I wanted to start a business, probably an online business considering the skills I have. The other trigger of those thoughts were because I wanted to experience and learn what it means to build a business. I never ran any business in my life so I saw this as a great learning opportunity, a path on which I can learn skills that I don’t currently have. The worst thing that could happen is if I fail, however, I’ll end up with experience and tons of learnings.
Obviously, the first thing that any developer would do is to start thinking about ideas. Ideas were never a problem for me but figuring out which ides is a good fit always was. This time I’ve decided to try a different approach and really think through the idea before I jumped on it. There were some criteria I wanted to run each idea through.
I wanted to solve a real problem, probably something I personally face
It should be for the market I know well
It should not be a new idea (it’s not going to change the world)
It could become a business
The golden rule of any idea is that it has to solve a problem that people face. In the past, I’ve added so many ideas to my notes so it was a matter of visiting the pool of ideas I’ve saved.
I knew from the beginning that I’d probably be more successful if I built something for developers because I know the market pretty well and most of my close friends and online followers are tech-based. I could use my network and audience to validate my idea and get a solid feedback before I commit to anything. This really filtered down all my ideas into a list of 2-3 things I could work on. One of the ideas was something I kept coming back to over and over again. It was something I’ve faced both at Buffer and during the work on my previous side-projects. A simple way to monitor scheduled cron jobs. Since one of the areas I own at Buffer is the analytics data infrastructure I have run a dozen cron jobs in the background to collect the daily analytics data for our customers. It has to be up to date. The Datadog monitoring service that we use at Buffer is really great but it’s primarily designed to monitor continuous services or servers. I wanted a simple dashboard where I could see the list of all my cron jobs, their statuses, and logs. Every day get a report of all ran jobs so I know everything is on track.
After picking this idea I wanted to see if there’re any existing solutions on the market. If there are it’s a good sign that there is a demand for certain tools. In fact, there were a couple on the market with different paid plans. I didn’t necessarily want to build something completely new because if I did it would have been so much harder for me to define and validate the market. All the existing solutions had paid plans so I knew people would pay for it. The next goal was to validate if my thinking is right by building and launching the initial MVP.
I spent 2 months to build the initial version of Cronhub (yes, I gave it a name). Something viable that I could send to a handful of my friends and Twitter followers to try. For the MVP I wanted something very simple but also valuable enough that people will pay for it. I know you may think that 2 months is a long time to build an MVP but I didn’t take the traditional “hustle” approach and instead.
Worked only 1-2 hours every day
Slept 8 hours every day
Watched Netflix whenever I wanted to
Fully rested on the weekends
Used the tech stack I felt most comfortable with
Since I have a full-time job I worked on Cronhub usually from 7 to 8:30 pm. I could also work in early mornings but I spend most of my mornings at the gym. There were some days when I felt mentally very exhausted after work and I took it easy but most of the time I stuck to my routine. I knew if I wanted to finish this project I had to keep the momentum and commit every day even if it’s a small change (can be a single line commit). Consistency has always been super useful for me to stay on track and ship. I used Trello to break down my project tasks into small milestones.
I tried to make each task very small so I can start and finish in a single day. Keeping tasks small helped me to ship faster and see my daily progress. When you see a progress it motivates you a lot and keeps you going. I think it’s a mind trick, maybe? Working on big tasks slows you down and eventually, you give up because you get bored and you want to jump on something else.
I never worked overnight. I went to bed around 10:30 every day and woke up at 7. Having a proper sleep is my number one priority. It defines the mental energy I have during the day and I can’t sacrifice it. Besides sleeping well I decided to spend most of my weekends on doing something completely different like playing soccer, watching movies or hanging with friends and family. Even though I love coding I know it’s easy to burn yourself out. Weekends helped me to refresh my brain.
I think as a developer you always want to use the hottest and coolest technologies. And it’s okay. I want that, too. However, my goal was different and I wanted to build and ship Cronhub as fast as I could with the technologies I already knew. I stayed focused on my goal and used Laravel and Vuejs. Cronhub is a single page application using Laravel for the backend.
Closed Beta Launch
On Feb 20, I finished the bare-minimum of Cronhub and was ready to invite the first pool of early adopters to try Cronhub. After my tweet around 20-25 people reached out to me on Twitter asking for an invitation and the feedback I got from them was super valuable.
There were couple reported bugs and some great feature suggestions that I’ve added to my feedback document. Keeping track of user feedback is an important step because it helps to identify the obvious patterns you can refer when you make product decisions. Overall the first impression and feedback were encouraging. Now I needed to continue improving the product and make it ready for the first public launch. I planned the first public launch to be within a month.
After three months, today, I’m launching my first SaaS side-project to the public. Yay!
Obviously, I’m nervous and don’t know if this is going to work out or not. However, I know this brings me one step closer to my goal. The goal to make Cronhub into a profitable online business where I can learn and experience all the hidden secrets of running a business. After all, what’s the worst that could happen? I’d learn so much!
I know maybe I’m too much focused on thinking about profitability but after building couple side-projects for free in the past I know it’s time for me to take my time a little bit more seriously. Time is the most valuable asset I have and I want to spend consciously. Building a paid product is way more motivating and it pushes you forward. Also, maintaining side-projects for free is expensive and I know it from my experience.
The past 3 months were really great timing for reflection as well as to evaluate what worked well and what didn’t. Every time I build a new project it’s a new learning experience. Each project is unique and requires a different thinking process around the product. As a product engineer I want to develop my product mindset and this helps.
Overall, I’ve learned many lessons that really helped me to start and launch an idea. I want to share the most important ones with you.
Solve a problem you personally face. This is so key because essentially you build the product for yourself, always keeping you in mind. This makes it a lot easer to make good product decisions. You know what questions you should ask and chances are higher that you ask the right questions.
Keep your tasks small. When you break down your project into pieces try to make them smaller. A good way to measure the size of the task is to ask yourself “Can I do this task in a day?”. If the answer is “No” then probably it’s a big task and you can break it further.
Sleep well and rest. I can’t stress how important the proper sleep is. You don’t have to work overnight. Focus on incremental progress and small daily commitments. If you don’t take care of yourself you will get tired soon and eventually give up.
Choose a market you know well. I’m a developer and I know this market well. I know what it takes to be a developer and how developer teams collaborate. This gives me a sense of things that will and won’t work out in this market. Of course, I can still be wrong but chances are a lot less.
Talk about your project. This is a challenging one for me and I’m still adapting to this. I don’t really like to talk about myself. I like listening more. It’s not easy for me to talk about the project I’m building because I’m a bit shy and don’t want to make an impression that I constantly talk about myself. However, I know I have to get the word out and market my project. That’s how others will discover it in the beginning. This article is an example of that.
Thanks so much for reading. I hope you enjoyed this story and learned at least one thing from it. I would love to hear from you, please feel free to comment with your questions. You can reach out to me on Twitter or email me.
If you’re a developer or part of a team that uses cron jobs you can try Cronhub for free. Use coupon “indiehackers” to get 20% discount if you upgrade to “Developer” plan.