This is the story of how I went from having an idea to launching Typehut in 30 days.

Typehut is a super-simple publishing tool for blogs, newsletters, changelogs, or any type of content you can think of. It's free to use and it offers a Pro plan if you need some customization. I'm using Typehut to publish this blog.

This article is a detailed write-up of the process I follow when I create digital products. How I come up with ideas, design products and interfaces, and the way I approach launching.

You can read everything from start to finish to get an idea of the entire process or you can use it as reference for whatever stage your product is in.

This process has taken me several years to develop, so I hope you find it useful.

I sometimes tweet about product-related stuff, in case you like this kind of content.

Coming up with ideas

I've tried many methods in the past to come up with product ideas but, one thing I've learned over time is that ideas show up when I'm not looking for them.

There's this old piece of advice that you should start by solving problems you have. That's great advice, but you need to learn to dive deep into the problems you encounter instead of working around them, which is what most people do.

The problem

Let me illustrate what I mean with a specific example.

When I'm not building side-projects I work at a startup called Factorial.

At Factorial, as our user base grew, the changes we were pushing started to impact more people, and we didn't have a way to let our customers know what was new. We were receiving a lot of support tickets every time we tweaked something in the product.

It was time for us to have a public changelog, one that we could share with our customers so that they would be up to date on what's new.

Since a changelog isn't something core to our product we opted for using a pre-built solution. I started looking for a service to publish ours.

Let's face it: a changelog is a pretty simple thing. Write updates, add tags, add a couple of GIFs and hit publish. Link to it somewhere in your product, and link to a specific release from a product newsletter. Easy stuff.

Turns out niche solutions were pretty expensive for what we wanted to do—a simple blog. I get it, when you build a niche product the use cases you cover are very limited, so you have to charge a lot more to offset acquisition costs.

Another option for us was to spin up a Wordpress or Ghost blog in some server. Install a theme that would fit our needs, and publish changes there. But it was hard for us to justify the overhead of having an entire blogging system for a simple changelog.

I thought about using a static site generator like Jekyll or Gatsby, but it would also cause a lot of overhead for what we needed.

Tumblr was an option. I used to create microsites there all the time since it was super-easy to set it up and start publishing. The thing with Tumblr is that it's focused on community and millennials sharing memes. That's great, but I didn't feel comfortable hosting our changelog there. We needed a professional tool, not a social network.

The solution

Now, what if there was a platform with the ease-of-use Tumblr offered, focused on publishing instead of social sharing. Agnostic enough that it would allow users to not only create changelogs like the one we needed but also any kind of article-based site. Simple enough that starting a new site would take less than a minute.

Every time I have an idea I make sure to write it down. I use Workflowy for that. I added the following to my list of product ideas:

- Micro-publishing for companies and professionals - Like Tumblr but for companies - Companies can have many streams - Each stream might be useful for a different thing - Easily publish many kinds of content from one place - People can subscribe via email to automatic updates - Entry barrier very very low - Use cases - Blogs - Changelogs - Newsletters

When I come up with a new idea, two things can happen. Either I discard it after thinking about it in-depth. On rare occasions, I keep coming back to it to the point where I convince myself that I should actually build the thing.

After a few days, I kept thinking about this one. Coming up with new use cases all the time and adding them to the list. I was starting to shape up the final product in my head. It became clear: I needed to build this thing.

December 1st: Product definition and roadmap

Starting from scratch is one of my favorite things to do. Sitting in front of a blank canvas trying to figure out what the solution to my problem is going to look like. It's a challenge, an opportunity to learn, a chance to discover something new.

I always start by building on top of my original idea. I kept adding use cases, thinking about what would be useful and what would cause bloating. Since my angle was simplicity, that last point was very important.

My goal here is to structure my thoughts and assumptions into a list of concepts that will become the product vision.

Researching competitors is also important at this point. You need to understand what the market looks like. It's the stage where you discover that similar products exist, which might be discouraging. If there are other solutions to this problem, that's actually validating your assumptions for the existence of the market. If you have a unique spin on it, you should be fine.

After that, I shaped up the idea of the product until it was very clear what the key features were going to be, and what I needed to build to launch an MVP.

Users need to be able to:

Create one or many sites

Publish free-form articles

Get a personal URL they could share with other people

Subscribe to any site and receive updates via email

Simple enough. Not an absolute minimum viable product, as I could build email subscriptions after launching the initial version. By making them built-in, I could access a set of use cases like newsletter publishing that otherwise would have been impossible.

It was a minimum valuable product.

Roadmap

Once I knew exactly what I wanted to build, it was only a matter of breaking the product apart into small enough chunks that I could wrap my head around.

I planned three total phases before actually launching, assigning an internal delivery date to each of them. I usually like to name these phases using the NATO alphabet, for no reason at all.

This is what the initial roadmap looked like:

- Alpha: December 8th - Brand + domain - Login - Posts API - Have one site - Create and edit articles - Bravo: December 31st - Have many sites - Signup - Email subscriptions - Custom subdomains - Public pages - Charlie (public launch): January 12th - Labels - Edit site settings - Cookies, terms & conditions, etc - Edit account settings - Upload images - Video for homepage

You may have noticed that's definitely more than 30 days.

I always try to plan in a pessimistic way, expecting things to be harder than I thought.

Later it would turn out that by the second half of December I was pushing code faster than expected, so I decided to launch at the beginning of January.

December 2nd → 3rd: Naming, branding, and UI

Naming things is one of the most difficult things to do. When it comes to digital products it's even harder since you need a good domain name to go with your product, and most good domains are already taken.

Most, not all.

I strongly believe in the importance of owning the .com of your product/company name. This is best stated by Paul Graham in his Change your name essay, but the gist of it is that owning your .com signals strength.

Opting for a .io , .co , .app , or similar extensions might be easier but it may cause visitors to be wary of the longevity or reliability of the service. A .com instills confidence.

If you're choosing your domain name, you should try to find a .com that's available.

Over time I've developed a systematic way of naming things, which you can use to name your next thing:

I use this service called Dot-o-mator to form words and check their availability as .com domains. I can't overstate how fast and accurate Dot-o-mator is, and how much time it has saved me.

To compose the words I create two lists:

The first list contains small words related to the product I'm building. In this case, some examples would be text , type , blog , or draft . Usually single-syllable words.

, , , or . Usually single-syllable words. The second list contains generic words that we can use as beginnings or endings. Words like air , base , cube , curve , flip , gram , hut , or line . I tend to use single-syllable words here too.

Once you have the two lists, add them to Dot-o-mator. In a matter of seconds, you'll see which of the combinations are available as .com domains.

That's how I came up with the name and domain for Typehut and many others I've used in the past.

Branding

When it comes to branding, I don't follow such a systematic approach but rather adapt to what I want the brand to convey.

In this case, I wanted to play with the name but keep it super-simple. The brand should stay out of the way, as the most important thing is the content published.

One thing I learned a long time ago is that your first attempt at designing something will never be the last one. It sucks, and sometimes it doesn't feel like it until at some point it does.

Having that in mind I started working on some initial concepts for the logo.

After a few iterations, I ended up with the final version.

User interface

The product is the most important component of the entire brand. It's what people know you for. The thing they're gonna be seeing and interacting with. It's important to get it right before anything else.

I actually started working on interface concepts before working on the brand.

Design system

The approach I follow when designing a new interface is to start by working on the design system.

If you break down interfaces to their most basic components, you'll find out that they essentially are collections of inputs and buttons.

I work on 4 things before doing anything else, and then build the rest of the UI on top of them:

Sizes: I work with what I call margin units. For Typehut, I defined the margin unit as 8px. All the spacings and sizes in the entire interface are multiples of this unit. By limiting the number of options when it comes to sizing, I can design faster and in a consistent way.

Typefaces: I decided to go with the default sans-serif for each operating system. San Francisco for macOS and iOS, Roboto for Android, and Segoe for Windows. I didn't want to load any external fonts, because that would have made sites slower. I defined all sizes and line heights for text between H1 and H6 and for paragraphs.

Colors: For the color palette, I defined 6 different greys and 4 primary colors. I picked blue for the main UI components because it would stay out of the way of the content.

Form elements: If you break down interfaces to their most basic components, you'll find out that they're glorified collections of inputs and buttons. That's why I build those first.

Navigation and layout

After I designed the main elements of the UI, I focus on what for me is the hardest but most rewarding part of product design. The navigation and layout pattern.

This is what defines the way your users navigate through your product and interact with it.

I like to approach navigation and layout design by defining some constraints. Limiting the number of choices you make yourself available also limits the number of patterns your users are going to have to learn.

In the case of Typehut, I wanted people to focus on one thing at a time. Embracing simplicity and ease of use. I didn't want to clutter the UI with all kinds of information, only the task at hand.

After a few iterations, I opted for a single-column design. A context-based header would change to adapt to whatever section users were in.

The article editor was going to behave like a lightbox right into the UI. But to stick to the original constraints, I ended up designing a separate view for it.

Final screens

Once I finished the design system and the navigation pattern, I put together some of the main screens.

Designing screens with finished UI components and navigation is like playing with LEGO. You can focus on choosing the elements that make sense for each screen and the rest is already done.

I finished the main flows, and the product was looking good. It was time to start implementing everything.

December 5th → December 31st: Development

Deciding the stack I was going to use was easy: I went with what I know best.

I had developed some apps in the past using Rails for the backend and Vue for the frontend, so that's what I chose. This project wasn't intended as an experiment or a way to learn a new technology. I wanted to get something out the door as fast as possible.

Setting everything up

Before starting to push code, I needed to have answers to some questions: where am I going to deploy it? am I gonna have the front-end code live in the same place as the back-end code? how should I handle authentication? what database am I going to use?

When I decided those things—single repo, pushed to Heroku, session-based authentication handled by Devise, Postgres—I could get started setting everything up.

I created the Rails app, a private repository in Github, installed Devise, webpacker, and configured some other stuff.

Everything was ready to start writing code.

Modeling data

The next thing I needed to do was to define the data entities. These are the objects that shape Typehut, and the relations between them.

For example, I knew that I was going to need Users , that the users were going to have Sites and that the sites were going to have Posts . That's the most basic data structure that I could build Typehut on top of.

Now, of course, it's not the most scalable data model. What if I wanted many users to be able to create posts for the same site? what if I wanted to charge based on the number of sites a user has? or what if users are going to have different roles?

I ended up making the decision to have the concept of Workspaces , to which users belong. The sites ended up belonging to those workspaces, which would have a PaidSubscription . That controls whether the sites in each workspace are part of the Pro plan or not.

After that, everything else was pretty standard. As I developed other features I added Tags , Subscribers and Themes to the data model, but nothing fancy.

API

Since I was going to build the front-end using Vue, I first needed to build an API into which I could plug Vue.

This API is super-simple since only the main interactions were going to go through the Vue app: managing sites and creating and editing posts.

To build this API, I needed a bunch of routes and controllers in my Rails app. The great thing about Rails is that I could pretty much code a working backend in less than an hour.

To test that the API was working I used Postman, handcrafting the calls acting as the front-end.

Sites code

After building the API I was able to push sites and posts to the database, so I wanted the backend to render those sites I was building.

My goal here was to get a perfect Lighthouse score and to make the sites load in under a second.

I chose to use Rails to generate user sites because I wanted them to be fast and lean. No javascript, no extra stuff. Only the HTML and some CSS to style it.

Front-end app

After building the site renderer, the API was at a point where I could build the front-end app and hook it to the backend, so I started working on that.

I chose Vue because of its simplicity and because I had already used it in the past. Vue has such a low entry barrier that you could read a tutorial on it and get started building complex apps in a couple of hours.

I use vue-router for all the routes in my application and vuex for my global store. After getting that set up, all I needed to do was to build the components and put them together.

The first thing I built was a list of posts. After that the single post view and then the editor. I kept adding functionalities to both the frontend and backend as I needed them.

Polishing the last details

Most of the initial features didn't take long to develop: I had a basic MVP working by December 8th.

Between the 8th and the 31st, I built missing functionalities, ironed out a lot of bugs, and polished the UI. Up until the product was at a point where I felt comfortable launching it.

I also built the public site, features page, marketing materials, etc.

It's the small details and general polish that take long to get right. Things like making sure the signup and login flows work right, the cookies and privacy pages are set up, or the email templates. There's a fixed cost when launching a new product that takes up most of the time.

Deploying

Deploying the application was easy because I started doing it early in the process. This had bitten me in the past, where deploying a project I had been working on for a long time took me several days.

In the case of Typehut, I decided to start deploying it as soon as possible and kept pushing updates to production and testing if anything broke.

January 1st → 2nd: Launch

By January 1st, I had finished all the basic stuff, so I decided it was time to launch.

Users could create sites, publish posts and have people subscribe to their sites. That was it.

I had no Pro plan, no paid subscriptions, no paid features. I was going to build those right after the launch, but I decided to keep them on the public site so I wouldn't lose signups.

I decided to launch on Product Hunt on January 2nd. Not January 1st because I thought there were going to be a lot of launches that day, and not that many visitors to the site.

Nowadays you can launch many times in Product Hunt so even though the product wasn't finished and it was missing a lot of features, I launched it anyway.

For the launch materials, I used a bunch of screenshots and the video that I recorded for the homepage. One thing I do when building products is to write down a bunch of different descriptions or pitches about the product. I used one of those for my Product Hunt page.

Product Hunt resets its products for each day at midnight. I didn't want my launch hour to be so close to that limit, so I set everything up and scheduled the launch for January 2nd at 00:38h.

I wish I could say the launch was a total success, but it was not. It also wasn't a total failure, it was more like in the middle.

These are the results:

Being one of the top 10 products of that day

Got 190 total upvotes

~250 users signed up right after launching

Measured conversion rate to be around ~10%

Got some coverage in other sites that use Product Hunt to get new products to write about

I got a lot of useful feedback and kind words, which I appreciate

So, not great, but also not terrible.

Apart from Product Hunt, I also submitted Typehut to some other secondary startup directories. That got me a bit more traffic at about the same conversion rate.

All in all, I'm currently sitting at 463 registered users, out of which 401 confirmed their accounts, 367 created at least a site, and 199 published a post.

During January—after the launch—I added the Pro plan. It included custom themes and domains, among some other smaller features and bugfixes.

What's next

My goal with Typehut is to build the simplest publishing platform in the market.

I believe there's a place for something a bit less powerful than Wordpress but a lot easier-to-use. A place where you can publish any kind of content and is as customizable as Tumblr, but focused on professionals and companies.

The truth is that Typehut is still far from that.

Site customization has a long way to go, as right now users can only add custom CSS. There's only one template available, instead of a marketplace. The public API doesn't exist, yet integrations are a core part of the product vision.

The core experience is there. Many people are already using it to publish their personal blogs, podcasts, product changelogs, and other kinds of content.

I don't want to build a product isolated from actual users, since I know I wouldn't build the right one.

That's why I'm now focusing on getting people to try it out. If you do and have feedback—or just want to say hi—hit me up at cesar@typehut.com.