2020

2018–

2017–2018

2017

2016–2017

2015–2017

2011–2015

Latika Sridhar

Atty Eleti

Bob Perry

John Palmer

internetVin

Olamide

Benji Taylor

Betty Wang

Abhi Vyas

HipCityReg

Toby Shorin

Kent De Bruin

Polly Rodriguez

Paco

Justin Seymour

Camille Hearst


I'm tired of working alone.

Since I started programming, almost everything I worked on outside of work and hackathons were solo projects. There are a few exceptions, but either timing wasn't right or initial interest in a project quickly turned into indifference.

Traditionally, coding was a solitary activity for me. I taught myself to code so I didn't have a bunch of computer science classmates to experiment with. Rather than put effort into finding someone to work with I just kept coding. It was easier in the short term.

Now, I'm looking for a collaborator.

A collaborator is not a co-founder. I don't want to start a company right now. I want to explore. A collaborator is someone you would continue working with if the current project didn't work out. You help keep each other sane and complement each other.

Jobs and Woz were collaborators turned co-founders. They did a bunch of projects before Apple: [blue boxes](https://en.wikipedia.org/wiki/Blue_box), Atari circuit boards, etc. They explored their interests and couldn't _not_ work together. If Apple wasn't a success, maybe they would have forever contently tinkered away in garages together.

I'm not looking for much in a potential collaborator. Someone that has wonky ideas and enthusiasm is preferred. Previous design or engineering skills would be nice, but aren't important. Location doesn't matter.

Most of our time would be spent getting to know each other and exploring things one or both of us are interested in. We would exchange excited text messages at random times about an idea one of us just had on the subway, go for aimless walks, etc.

Before we build anything, it's important we can empathize with each other.

A little about me: I'm an engineer and occasional designer. I mostly build for the web, although I've made mobile apps in the past. I'm comfortable with frontend, backend, and devops. Currently, I work on [Patreon](https://patreon.com) remotely from NYC. A few projects I'm proud of are [Mute.vc](https://mute.vc), [Notational](https://notational.co), and [this blog](https://meagher.co).

If working together sounds interesting, or you have a friend that might be interested, send me an email ([tom@meagher.co](mailto:tom@meagher.co)) or [Twitter DM](https://twitter.com/awkweb) so we can start chatting. You can simply say hi and that you read this post.

---

Thanks to [Latika Sridhar](https://patreon.com/latika) for reading drafts of this.



Looking For A Collaborator


Over the last few years, I've made an effort to stop using Google products and start using products made by folks that (I think) are better stewards of my data, attention, and privacy.

At this point, there are a couple solid [alternatives](https://restoreprivacy.com/google-alternatives/) to every Google product. [DuckDuckGo](https://duckduckgo.com/) is my primary search engine, Apple Maps has improved significantly, [Simple Analytics](https://simpleanalytics.com/) is good enough and respects visitors tracking preferences, etc.

One product I hadn't looked at migrating from was Gmail. I've used it for more than a decade and resigned to the trade-offs long ago. A recent thought I had made me reconsider: Gmail controls your email address, not just the email client.

In hindsight this is obvious, yet still unsettling. My account could be suspended for some reason and I would lose access to my email and anything else that is connected, like bank two-factor authentication codes. A quick search for ["gmail account suspended"](https://duckduckgo.com/?q=gmail+account+suspended) yields a collection of horror stories.

This problem isn't unique to Gmail either. Any email service that doesn't let you use a custom domain has this problem.[^1] So I decided to set one up. Since I didn't want to blow up my current process, I decided to use [G Suite](https://gsuite.google.com/) (sigh) for my custom email.

This is a war, not a battle. It will take time. First, I create the custom email. Then, I start propagating it across all the services I use. Finally, I switch to a new provider. The fight to own your email address is worth it.

With my own custom email address, I will be able to send and receive email from <CopyEmailButton /> with near 100% uptime. The email service I'm using might get disrupted, shut down, or suspend me, but now I can take my address with me anywhere.[^2]

And there might be [somewhere better](https://hey.com) to take it soon.

[^1]: The primary problem is not being able to send or receive emails now and in the future. Accessing past emails is not as critical in my opinion.

[^2]: As long as my domain doesn't get stolen



A realization that I don’t own my email address.

Own Your Email Address


It's important to [write on your own website](https://bradfrost.com/blog/post/write-on-your-own-website). It helps with building your personal brand, controlling your content, and [many other things](https://indieweb.org/why). But what's the best way to build a website to write on?

All at once? No. Piece by piece? Closer. In increments? Bingo!

Fundamentally, this is not a big discovery. Most contemporary product development processes encourage breaking projects into smaller chunks. It makes sense to approach a personal blog the same way: Build one increment after the other.

Unfortunately, for past blogs, I always tried adding everything at once. I felt like I needed comments, tags, an RSS feed, etc. in order to start writing. All of these features are pretty simple individual tasks, but collectively they suck the joy out of writing.

My goal was to spend more time writing and less time coding.

The concept of "incrementally building a blog" gave me permission to not build anything until I stubbed my toe while writing, publishing, or reading a post.[^1] It empowered me to worry less about the packaging of my ideas and focus more on how I communicated them.

Practically, how does this process work? First, I write a post in [Markdown](https://www.markdownguide.org). Then, I add it to my local blog site and see how it "looks." If the post renders incorrectly, I'll add the simplest fix needed to hit "publish."

Code snippets are a good example of a lurking stubbed toe. None of my posts contain inline code or code blocks yet. Eventually some probably will. Until they do, there's no reason to spend time adding support for syntax highlighting or other code-related features.

Another happy side effect of building my blog in increments is it encourages me to write more. There are features I want to add (search, tagging, an archive), but don't make sense for a blog with only a few posts. There's no utility in pagination unless I write more posts than fit on a page.

Currently this process works well. I anticipate it will continue. It also protects me from rushing to add a shiny feature I see on another blog.

[^1]: I finally put a name to this idea when I saw [Frank](https://frankchimero.com) and [Jonnie](https://destroytoday.com)'s blogs. Both are redesigning their blogs publicly by [documenting](https://frankchimero.com/blog/2019/redesign) [changes](https://destroytoday.com/blog/hello-world).



Focus on writing. Only add new features when you need them. (You don’t need pagination until you write more posts than can fit on a page.)

Incrementally Building A Blog


Something I've had top of mind for a while is the idea of building paid software. Not in a business-school-make-money kind of way though.

I'm interested in building paid software for the relationship with the people that use the software. How can I build something simple that helps people live better, or even just less painful, lives in a respectful way?

These are both things you can do with free products, but it's not quite the same. Paid products force prospective customers to consider the value and if they want to opt in. There is an explicit value exchange that sets an important tone: people pay for the product and can continually assess whether it meets their needs.[^1]

This relationship is beautiful. It's good for business if product makers continue making improvements and treat product users well. In turn, users help guide what goes on the roadmap.[^2]

Now that I [launched my last product](/mute-vc/) and am side-project-less, I spent some time noodling about general ways to approach building paid products. I'm sure I missed some, but these all seem like decent starting points.

#### 1. Reduce complexity

Complexity is the enemy of many things. Software loves to morph into complex, tangled spaghetti over time. One route to making a paid product is taking a feature of an already successful, yet complex product and giving it new life. Letting it shine on its own. Unbundling is a subset of this.

Doing one thing really well is often better than doing a bunch of things that are mediocre.

#### 2. Redesign

If an old product escaped feature-complexity, it's probably visually bloated or the design could use a touch up. Slapping a new coat of paint on the same or similar features, or even redesigning from the ground up with fresh eyes, will make it look close to brand new.

Great design is not easy, but a better design is often as simple as reducing visual clutter and sorting out hierarchy. Beware of just copying whatever design is popular or you'll redesign again in a couple years.

#### 3. Privacy-first

With data leaks and breaches happening more in recent years, people are becoming more privacy-conscious. Taking an existing product and making a privacy-focused version should attract some interest, especially if the existing product/industry cares very little about privacy.

You can build a privacy-focused product through marketing alone — users will feel good, but it will all be for nothing — or you can do the hard work to ensure everything is actually private. This "hard work" might be as easy as upgrading to a more modern tech stack or architecture.

#### 4. Liberate data

Tools that help users tell better stories or make better decisions are extremely useful. Finding signals for users from their existing data or enriching their data with novel sources will help them do both of these things.

Tactically, take some data and present it in a different way, or give a group of people access to data they didn't have before. Humans are really bad at processing and finding trends in high-dimensional data so even if the tool just prevents comprehension errors, it's worth something.

#### 5. Build on high-growth platforms

When new, high-growth platforms spring up, they can't build everything for their users. Find out what these people need and make it. It might be hacky at first, but a lot of tech platforms open things up to developers nowadays. Being the first "app" in a platform's "store" can lead to fast growth.

This strategy could also work for more mature platforms, but a lot of the low-hanging, tasty fruit will already be picked off.

#### 6. Listen to desperate users

Given a large enough company, old enough software, or both, there are groups of folks that hate their job because they are tormented by the same piece of software every day. Find and listen to them. Those that are experiencing a "hair on fire" problem want to find a solution quickly.

Potential blockers here are the people with the acute need don't have purchasing or decision-making power.

#### 7. Solve your own problems

If you pay close enough attention, you can find things that are annoying about almost anything, including your daily life. Likewise, you can also notice shortcuts that others don't. Productizing a solution to these annoyances or making shortcuts more accessible/obvious will give you at least one user — you!

If you don't think you have any problems, ask someone else about theirs. Try to notice how they work too. Is it different from what you do? Is that better or worse?

#### 8. Internal tools

Almost every tech company builds the same internal tools. Find out who built them and ask them why. Did their last company build the same tool? If you work at a tech company, especially a large one, there are a lot of potential customers walking around.

If you think companies won't switch away from their internal tools and buy your productized version, you are wrong. Internal tools are often very rough and expensive to maintain. Product manager and CEOs would love to use your product if it reclaims engineering time. Maybe your current PM or CEO is your first customer?

***

Closing notes: I've built paid products before, but as part of large teams. There's something different about _getting_ paid to make a paid product and being the one that _gets_ paid by the paid product.

[^1]: Free products have more abstract value trade-offs (i.e. time/attention and instead of money) so there's a lot less friction to amassing users.

[^2]: Calling people that use a product _users_ is lazy. There are [other options](https://jnd.org/words_matter_talk_about_people_not_customers_not_consumers_not_users/), but since this article is very general, I'll continue using the term. At [Patreon](https://patreon.com), we say creator, patron, fan, etc.



Approaches for building products you can charge for.

Thoughts On Building Paid Software


Yesterday, I launched a quick hack I did over the holiday break: [Mute.vc](https://mute.vc). It's a simple web app where you can individually or bulk mute/unmute investors so you don't have to see their tweets.

I [posted it](https://news.ycombinator.com/item?id=22044945) on Show HN and it hit the front page after a half hour. Right away, traffic spiked. I was mostly unproductive for rest of the day replying to comments, refreshing the analytics, and riding the wave.

Not sure why, but at some point after bouncing around between #11-17 for a few hours, the post dropped to #45. Maybe because some people started talking about politics in the comments (think mute.politics). At that point, with traffic dying, I thought it was over.

Surprise! It wasn't.

On a whim I DMed [@vcstarterkit](https://twitter.com/vcstarterkit). They tweeted it out. And traffic took off again!

> When engineers have had too much of VC twitter, they make an app to mute VCs
using the Twitter API: [mute.vc](https://mute.vc)
>
> — let me know how i can be helpful (@vcstarterkit) [January 15, 2020](https://twitter.com/vcstarterkit/status/1217241074155962368)

Some other big accounts sent out tweets ([@steveklabnik](https://twitter.com/steveklabnik/status/1217111081077874689), [@KristyT](https://twitter.com/KristyT/status/1217255843273461760), [@dhh](https://twitter.com/dhh/status/1219302297928224768)), which helped even more. Overall, I was surprised at how well Twitter performed given I had no plan for it. Big thanks to [everyone that tweeted something](https://twitter.com/search?q=mute.vc%20since%3A2020-01-13%20until%3A2020-01-18).

Launch aside, what was the motivation for [Mute.vc](https://mute.vc)? First, to be clear, VC is important and necessary.[^1] What's not important or necessary is the thought leadership and platitudes a lot of investors tweet out from their armchairs.

I get why they do it — to build their brand, stroke their ego, and many other reasons — but it was tiresome, especially when I was trying to build things. The problem wasn't who I followed.[^2] Rather it was all the VC content that kept surfacing in my feed via retweets, favorites of people I follow, and recommended tweets.

I was tired of having so many [ideas in my mind](http://paulgraham.com/top.html) about voice apps, the future of work, no/low code, crypto, ISAs, etc. All things that I don't care about.

After noodling a bit more, I [posted the idea](https://www.are.na/block/5698385) to my [Random Public Ideas](https://www.are.na/tom-meagher/random-public-ideas) [Are.na](https://www.are.na/) channel, and people seemed to like it. I was encouraged. I joked about it with a friend later that week and realized it would be a fun, quick hack to work on. Much to my delight the [mute.vc](https://mute.vc) domain was available so I got to work.

I spent a week building everything out and another week polishing until it was time to post. It was all worth it for testimonials like this:

> Real. And easy! I just muted, like, over 100 VCs in less than a minute! [https://t.co/MMMcaVZs5b](https://t.co/MMMcaVZs5b)
>
> — Peter Merholz (@peterme) [January 15, 2020](https://twitter.com/peterme/status/1217264622266277888)

Overall, I learned a lot from the launch. My biggest takeaway is to "show, not tell" when it comes to a product landing page. While above average (I think), my design described what the product did with only text! Confused or curious visitors would have benefited from an interactive demo, or at least a screenshot, of the product.

***

Some quick closing notes: I didn't go into implementation details in this post. You can check out the [code](https://github.com/tmm/mute.vc) on GitHub. Also, I didn't talk about the launch day stats either. Here are some quick figures as of 1/18/20:

-   89,467 total mutes (across 200 VCs)[^3]
-   10k page views (3.6k from Twitter, 2.4k from Hacker News)
-   2,551 attempted auths
-   715 successful unique auths (a.k.a users)
-   A bunch of unsuccessful auths (people churning at Twitter oauth step)
-   1,634 toggles to dark mode
-   21 new Twitter followers

For the most up-to-date stats, check out the monthly live analytics at [mute.vc/stats](https://mute.vc/stats).

Edit 1/16/20: Mentioned in [The Verge](https://www.theverge.com/interface/2020/1/16/21067483/chris-evans-starting-point-vanity-project-captain-america-democracy)

Edit 1/20/20: Posted on [Product Hunt](https://www.producthunt.com/posts/mute-vc)

[^1]: That said, there are a non-trivial number of bad investors that I'm sure are lovely people personally, but professionally, are not. They treat founders poorly, promote their own agendas/companies without disclosure, etc. all while pulling down [absurdly large management fees](https://hbr.org/2014/08/venture-capitalists-get-paid-well-to-lose-money). (Watch [Chamath's lashing](https://www.cnbc.com/2018/10/10/start-up-economy-is-a-ponzi-scheme-says-chamath-palihapitiya.html) if you want to rage.)

[^2]: Maybe it is a little bit who I follow. I like following people in tech. VC Twitter overlaps significantly with Tech Twitter.

[^3]: Due to Twitter's rate limit and speed at which I wanted to launch, I only added 200 investors to the [list](https://twitter.com/awkweb/lists/investors). The investors were randomly selected based on who I knew and simple searches. If you are on the list and want to be removed, I'm happy to do so.



Tom Meagher

Presence

Writing

Timeline