From idea to paying customer Intro Linen is a tool to sync Slack and Discord community threads and put them on a Google-searchable website. I wrote the first line of code in early Feburary and 2 weeks later I got our first paying customer for $1,000. I want to talk about the process that we took from picking the idea to actually getting a paying customer and all the trade offs that were made in the product on the way. Ideation But saying that I started working on Linen in early February is a bit misleading. Before I wrote a single line of code I had spent a week talking to potential customers and even before that I had spent a week doing customer research and identifying potential ideas that I wanted to work on. In total it took me around a month to go from having an inkling of this idea to something in customer’s hands that are willing to pay for. For most software engineers once they have an idea the first thing they want to do is build it out and thinking that they can build it in a weekend. But customer research and idea discovery is a very important part of the process that most neglect. I’ve made this mistake far too many times over a dozen side projects and startups that didn’t go anywhere and made sure to have a bit more of a methodical approach to Linen. I started out by making a list of ideas and pain points that I have noticed. I took note to anything that has been recurring and have experienced in a professional capacity. I then took note of anything that I had a competitive advantage in. Something that I am a domain expert in or something where I know who the first 10 customers are. After spending a few days on ideation the one pain point I noticed that was unique to me was that Slack is poor for knowledge retention for communities. I had seen this problem personally on my previous open source project github.com/papercups-io/papercups. I also had a unique advantage of being really familiar with the problem and being an open source founder I had built a relationship with other open source projects so I knew where my early customers was going to be. At this time the idea hasn’t fully formed yet it was purely problem discovery. After I had the problem in mind I spent a few days doing research on different alternatives and ways of solving this problem. I wanted something that I would have wanted as an open source maintainer. It needs to be a tool that didn’t require a lot of maintenance and it can’t be another separate place to manage the community. I remember seeing a product called spectrum.chat a few years back. A big reason that I thought spectrum.chat was interesting was because of the Google-searchablility of a server side rendered app and that was when I got the idea for Linen. Customer conversations It was around a little over a week when I decided I wanted to work on Linen and had a clearer idea of what it was. Again I’ve made the mistake of building it before talking to potential customers in the past. I could have made an excuse that it was a problem that I had so other companies would want it too. But after being burned too many times I decided to spend the week scheduling calls with other open source maintainers and founders. I spent the next week hoping on calls with potential users and even got a 1,000 dollar commitment for an annual subscription of Linen before building it. For the first half of these calls I only asked non leading questions about how they managed their communities and purely coming from a learning standpoint. After the user research I then mentioned the idea I had been working on and see how they reacted to it and if they had any feedback. I ended with a few enthusiastic customers and I threw out a few price points to see how much of an interest they had. Surprisingly one was willing to commit $1,000 a year for Linen. After 15 of these calls I had enough conviction to start building Linen’s MVP. MVP After these conversations I had a sense of what was important for the potential customers and I could boil it down to its essence. One common issue with MVP’s are the issue of scope creep and eventually it becomes a laundry list of extra features that didn’t need to be there. Customer research and feedback will clarify the MVP a ton. Additionally I set a deadline of 2 weeks for myself to build the first version. This forces you to strip out anything that wasn’t essential. I then wrote down all the features I want to include on a list and even more importantly which features are not. These steps helped me avoid scope creep and keep me on track. These were my features below: Features: - The ability to sync Slack conversations to a website - A decent looking website - A way to put Linen under someone’s domain Anti features: - Payments/Checkout flow - Sign up/Sign in - Landing page - Self service onboarding - Discord I was a bit rusty coding wise since my last project I hadn’t done much coding for the past few months so a two week timeline was going to be very tight. I decided to remove most of the onboarding and self service features. I could however work around most of this by manually onboarding customers. This had the added advantage of talking to the users and building a personal relationship with the customer. Since I had a list of early potential customers that I had been in contact with. I didn’t even include a landing page as part of the MVP. Eventually adding the landing page almost two months later when I wanted to do a Show HN. You’ll need a landing page if you don’t know how to reach your first few customers (but you probably shouldn’t build a product unless you know how to reach your first few customers…) Manual onboarding The onboarding flow ended up looking something like this: - Schedule a call with a potential customer - Send them a Slack authorization link where they would click on it giving our Slack bot the proper permissions - The API would then redirect them to a blank white page with the words “Syncing in progress” - I would frantically run a script in the background that actually trigger the sync locally ( I had to do a manual sync locally because I was using nextjs and hosting on vercel which didn’t support background jobs) - I would then make small talk to distract them on how long it would take 🙂 - Once it was finished I sent them the link of the page that was finished along with DNS instructions to set up subdomain forwarding I had to do a manual sync locally because I was using Nextjs and hosting on Vercel which didn’t support long running jobs. Instead of spending a bunch of time with a docker container or VM for a background job I decide to do it manually since it meant being able to hit the two weeks goal. An accidental benefit of this was I was able to watch the script crash and fail many times because of time outs and bugs. This actually help me build a much more robust syncing process later since I wasn’t able to test this out on many different communities with different members. Finally if they were ready to pay I would send them a Stripe checkout page for payment and I would then update a field in the database manually of whether the user was a paid user. Obviously this process wouldn’t scale and it took a lot of manual time for the early customer onboarding. I could have spent 4-5 weeks coding and polishing up the onboarding process and getting payments ready but as a solo founder it would have been difficult to keep momentum going. Most startups and products lose morale before they run out of money and part of the reason you want to move fast is to build momentum. It will help keep your spirits up when things get tough. In the end I shipped Linen with two pages, the channels page and the threads page. The first version was rough and brittle. It didn’t have mobile view support and syncing was flakey but most early adopters are fine with the product as long as it is improving rapidly. There would be times when customers ask for a feature and I would build it out within the next few hours and get back to them on it. They were always surprised by it because most companies don’t listen to customer feedback and if they do it takes months and years before implementing it. Since then we’ve automated the onboarding and have synced over 2 million messages with community members of totally over 170,000. The product is fairly robust right now and we have an actual backend service that handles the syncing. Take aways In summary I had spent one week on thinking and brainstorming different ideas and picked one where I had a unique advantage in. I then spent another week doing customer research and product research on the problem and got a pre commitment for $1,000 dollars. I then made sure to ship very quickly to keep the momentum up. I used a lot of manual process to make up for the lack of features. And finally once that is shipped I made sure it was improving quickly and constantly.