The making of a web product using Meteor

Jeffrey Wyman
Todoist Templates
Published in
6 min readApr 16, 2016

In this post I break down the reasons for creating it and the build process thus far. Using the open-source Telescope, I’ve built a quick and dirty prototype web app called TodoTemplates — a community gallery of Todoist projects. So far it seems to be useful, with about a dozen submitted projects and a steady increase in traffic.

If you’re unfamiliar with The Todoist Team, they create a task management app that’s like a to do list on steroids.

Here’s a snapshot of the finished prototype.

Screenshot of the first working prototype: todotemplates.com

If you recognized the layout, yes it’s a product hunt clone! It’s built on the open-source Telescope app.

Why create this app?

A recent Todoist update in late 2015 allowed users to import and export projects, with a convenient one-click import button. After reading about the update in a blog post, I came across this comment:

I was looking more for a sort of public repository

This makes total sense. I felt frustrated too. Users could now share their projects — but had no way central method of finding them. Imagine Twitter without any hashtags. Actually, imagine Twitter without hashtags OR a feed.

Solve my own problem

I’m an avid fan and heavy user of Todoist, so naturally I don’t mind taking part in building something I might use myself. I love watching how other people use programs and how they can adapt it to their workflow. It’s like a recipe for a secret sauce.

This is also why I love “How I use ___ in my workflow” articles (ex. Workflowy). What I didn’t know was how many people felt the same as me: a little lost when it comes to “task management best practices.”

The goal of the site was pretty simple. I wanted to answer this question:

Would Todoist users find a gallery of projects useful?

I’ve never built a web-app or information product, so my expectations are pretty low — I’m not trying to sell anything or change the world (though maybe I should be?). It’s more of an experiment. If it fails — no problem, I’m not attached so I won’t mind. But if it succeeds… wait, what does it mean for it to succeed? That part I haven’t really figured out yet.

If you’re like me, you’re all business. Results oriented. Productivity focused. A go-getter on the fast track to getting stuff done. Sometimes we all get a little caught up in reaching for our goals, shooting for the moon, going full-speed. And then we get disappointed at the first sign of weakness or when the results aren’t positively through the roof. As adults, we forget that we still need play. We all need time to explore our crazy ideas that in all likelihood won’t work, but might just be fun to try. In the process, you start to see other opportunities.

The build process

Getting excited about the idea, I spent a few hours of my limited free time building an app on Bubble.is. Not being a great coder, the idea of building an app without coding is pretty damn cool. Attracted to the thought of super-fast production and validation, Bubble grabbed my attention for a solid 3–4 hour block.

Ironically, it wasn’t until I had built out the entire UI with 2–3 working pages and user login/authentication, I came to realize…

How am I going to let users submit their posts? Fuuuuuuck. This is going to take a LOT longer than I thought.

I sped through design and development without sketching the UX. You see, I tend to procrastinate a fair amount. So when I find the (rare) motivation to get stuff done, I try to take full advantage of it. In this case, I was happy to make some progress on the idea even though it produced nothing.

You see, I had done a little digging through the sparce forums on Bubble.is, trying to understand how to build on their platform. I managed to make a decent prototype, but really had no clue what I would do next. The thoughts of user posts, moderating posts, spam, etc. all started “bubbling” only minutes after I felt accomplished and satisfied. Figuring this out on my own is going to be an uphill battle. So much for that.

Luckily I had played around with Telescope before and knew that it had the user submissions stuff figured out. I was rusty with Meteor/Javascript so it would still be a while before I could launch and validate the app. But, at least I knew which direction to go in. Sometimes this is the most important part of your work.

It would then take several weekends, maybe about 25 hours total, before I would get the site up and running, with working posts.

  • Logo design — 2 hours
    I spent a few minutes in Squarespace’s logo builder to come up with a logo. I found an icon that matched what I thought TodoTemplates was about (finding different ways to work) and looked it up on thenounproject. Later I adjusted the style in Adobe Illustrator.
  • Color palette — 1 hour
    Love love https://coolors.co. They really make it easy to experiment with different colors, meanwhile selecting the ones you want to keep. I can’t remember where I found the palette, but I got some inspiration from their “picks” category. I wanted something that used the lovely red from Todoist but also had some elements of professionalism and boldness. It takes guts to share your work.
  • Copywriting — 4 hours
    I spent a fair amount of time working on the exact wording of the site, how I wanted to present it to users, what it should really be about. I settled on “TodoTemplates” instead of “TodoistTemplates” because it’s a little simpler to type and it might keep the door open for other programs (Wunderlist or etc.). In general I think I’ve cut back 70–80% of the amount of words used on the site, compared to when I first wrote all the copy. I had each project with full blog posts in their description. It was just too much.
  • Web development — 16 hours
    Telescope has some decent documentation and very helpful YouTube tutorials, so this was fairly quick to learn. I used app.meteor.com to launch a basic prototype, but it was terribly unreliable. Their free hosting tier was riddled with excessive downtime and “maintenance.” I decided to go with digital ocean and haven’t looked back since. Currently using Atom editor, syncing to a Git repo, and one-line deploying with “Mup deploy”. I have to say it’s a pretty convenient workflow.
  • Social Media — 2 hours
    I knew at the start that this would take a lot of effort to get promoted, seen, and adopted. Created an account with Twitter and FB. After using FB’s demographic tool, I found that there’s apparently a huge market for Todoist on FB (a few million likes, with 30k+ followers). The easiest method to promote would be to get a guest post on Todoist’s blog, but might be a stretch since I don’t really have any relationships with their team yet (besides hounding customer support with feature requests).
  • Reddit — 6 hours
    I had been helping some users in general on /r/Todoist around this time, and noticed that the sub has been pretty quiet lately. I PM’d the moderator and asked to help. After he saw my helpful posts, he was happy to let me join the team. Since then, I’ve spent a couple hours per week helping answer questions, fixing up the subreddit, adding information, etc. So far, the subreddit has been steadily gaining traffic & subscribers, so I’ll keep on this.
Traffic stats steadily increasing in /r/Todoist (taken in mid-April)

Tune in for the next episode where I talk about the testing process with users and why I think this product has already been validated. And if you haven’t already, check out todotemplates.com and sign up to our email list.

Thanks for reading!

The testing process

After getting a few users to post comments and a couple projects, I started to reach out to users. I looked up some who wrote comments on the Todoist blog, gave a quick shout on the Twitter, and even went so far as to write directly to some support reps at Todoist to get their opinion.

(to be continued…)

--

--