Brick

I am running a startup — Brick.

It's like Notion for making sites. You write text and it's already online. You can customize CSS, add JavaScript, connect a custom domain, etc. It's pretty neat.

When I started Brick, I just wanted something to make web pages quickly. I didn't have specific usecases in mind — just "eh, whenever I want to make a web page I'd like to use Brick for that".

I remember talking to somebody who could connect us to potential investors, and they asked "who is your target audience?". I came up with something — but I don't remember what exactly. I felt apprehensive about saying "I don't know who Brick is for, but it's going to work out".

Soon, Brick will be two years old. We have a few thousand users, and the sales on SaaS Mantra are in five figures. I feel less apprehensive now.

I don't know what Brick is for.

Or, to clarify: I don't want to follow the path of "create user personas and usecases, optimize the product for them". I tried and I don't enjoy building a product in this way.

What I enjoy doing, apparently, is filling niches.

---

Everybody makes fun of "Uber for X", but I think everybody is wrong.

I suspect that "Uber for X" really means "a way to get X that's a) predictable, b) fast, c) done via an app, d) skips negotiation". The last part is crucial.

A freelance marketplace, for instance, doesn't count as "Uber for web design" if you have to spend hours talking to freelancers and answering their questions and waiting for them to accept/decline the project. There is too much negotiation going on.

Similarly, Airbnb is more of an "Uber for apartments" than Craigslist. Etc.

So, we have an axis: "less negotiation / more negotiation". And then, "why should everything be uberified?" becomes the wrong question. It's not that everything should be uberified — it's that now we have the technology and the blueprints to fill some parts of the design space that were previously empty.

Roam is another example. The Roam team has spent years trying to figure out how to turn the idea of "what if categorization and hierarchy aren't necessary?" into a product, and now Roam exists and everybody can steal their blueprint. Many people will. (Notion is already trying, for instance.)

Is Roam inherently better than traditional notetaking apps? No. Is it better for some people? Yes. And it's a less saturated niche, so now a thousand Roam clones will bloom.

This is how it works. Somebody spends years to venture into the unexplored part of the design space and build something that wouldn't be too bad (which is hard because you can't steal others' ideas — the niche is unexplored).

Then others can start filling this niche. X but private. Uber for Y. Mexican food, but vegan. Apps with chat-based interface (see ChatOps). A language similar to Z, but functional / Lisp-like / whatever.

---

And now, back to Brick.

Instead of thinking "who is it for?", I want to know "what niche in the design space does it fill?". Then I don't have to lose sleep over "but is this niche worth filling?" — I think most niches are worth at least exploring.

Site builders have the following axes:

① Document-based (blog engines, GitBook, etc) vs layout-based (Squarespace, Tilda, etc) vs template-based (WordPress?). Do you want to arrange design blocks on a canvas, or do you want to write text? For a landing page you probably want a canvas, either free-form or linear (stripe 1, stripe 2, stripe 3). Brick is firmly document-based — we expect that you'll mostly want to write text.

② Geeky (anything having to do with Git or Markdown) vs non-geeky. Static site generators are all in the geeky category. Brick is is non-geeky — it's a WYSIWYG, SaaS, closed-source product.

③ Small-scale vs large-scale. On Flickr you can have a photographer's portfolio with thousands of photos arranged in various ways. Shopify lets you build an e-commerce site with thousands of products sold. Wordpress lets you set up a news site with tens of thousands of articles, hundreds of contributors, custom templates, complicated rules for showing related stories, etc. Brick doesn't try to be any of that. This is also why we have an "instant save" system instead of the usual "drafts + a post pipeline" system.

④ Social vs non-social. An example of a social site builder would be using Facebook for business pages. Brick is non-social — no comments, no "story discovery" à la Medium, no reposts, no discussion boards, etc.

⑤ Extensible vs non-extensible. If you grow beyond the intended usecase of the platform, will it be painful-but-possible, or will it be actually impossible? Brick wants to be on the "painful-but-possible" side. We have CSS customization, we have custom JavaScript, we will have a public API, etc. Facebook, on the other hand, is on the "impossible" side.

There are definitely more axes, but it's enough because most choices are incidental here — for instance, I don't care much about Brick being social or non-social. The first three axes, however, are the axes I actually care about.

In general, "text" is a niche I personally get value from. I have a gut feeling that "text-based, small-scale, non-geeky" is a niche worth exploring, because I was drawn to this niche throughout my life and most solutions that I had found weren't simple enough or had too much friction.

---

"So you know what Brick is for, after all"

No. I know what kind of preferences Brick is for. I can't predict the specific usecases.

My hypothesis is that if I make a general-purpose tool that fits a certain preference set, people with those preferences will be using it for.. everything. This is what's happening with Trello, with Google Sheets, with paper even.

We are making a specific kind of paper.

For now.

Some numbers:

• ~100 new users (purchasing ~200 seats in total)
• ~20 new feature requests, we had to start a public roadmap
• 7 public reviews (all positive), ~70 conversations in the helpdesk, ~40 questions on the deal page

In terms of motivation, this is hugely helpful. The money is nice, but we didn't need the money nearly as much as we needed the questions & feature requests & knowing that somebody actually enjoys the product we're building even despite all the missing features.

A side-note: doing something for the second time is much easier than doing it for the first time. Now that I have the SaaS Mantra experience, I'm going to start doing something like this with all my future projects. (Either that, or finding investors. But hey, need to find investors for Brick first.)

A few months ago SaaS Mantra reached out to us and offered to promote Brick on their site. The idea is: they sell lifetime subscriptions to Brick (with a huge discount) and take a cut of the profits. You can see how the sale looks here.

This is turning out super well. Like completely unexpectedly well.

• The sale has been live for two days and we've already made more money than in the entire existence of Brick.

• We suddenly got a ton of new users with new interesting ideas about how Brick could be used (e.g. as a headless CMS).

• When preparing for the sale, we had to implement a few cool features (e.g. collaborative workspaces and sign-up by email) that we would likely have spent a longer time implementing otherwise.

• We were also motivated to write a roadmap, start a knowledge base, etc.

I think so far this has been the best thing to happen to Brick, much better than reaching the top page of Hacker News a year ago.

Viva la SaaS Mantra!

I have found it very important to do calls with users — they often have ideas I wouldn't have thought of, or usecases I wasn't aware of, or they know which communities Brick could be marketed in, etc. Oh, and I also feel more motivated after such calls. Overall, so far I haven't had a single call I wasn't glad about afterwards.

During the calls, I always ask "what do you use Brick for?", "what were you using before?", "what is the biggest painpoint right now?". Those questions serve as conversation starters — we can go anywhere from there.

I also often try to share as much about our future plans as possible, because the best time to get feedback about a plan is "quite a bit before you started implementing it". The simplest example: if I notice that nobody is excited about a planned feature I am excited about, I would reconsider it. If I tell someone "I guess feature A could also be useful for usecase X", they might reply with "and Y, and Z". Every plan becomes better when shared with someone.

So — a few days ago I had a call with Squid, running a blog at squid.brick.do. In this particular case it happened like this: Squid had a Calendly link somewhere on his site, my co-founder Andrey noticed it, and scheduled a call.

What did I get out of the call?

🏎 Squid mentioned that for him, Brick's main selling point is speed. This is useful to know, because it lets us not spend any mental effort on questions like "do we keep this bit of code simple and move on, or do we put extra effort into making it fast?". It's easy to become lazy when nothing seems to matter much; since now we know that at least one thing (speed) matters a lot, we get an extra bit of motivation for free.

🧠 An idea of a quick page switcher came up. When a feature idea comes up, I ask "what is the best implementation of this feature you've seen?" — Squid mentioned Discord. So if we steal a quick switcher, we'll know where to steal it from. Another thing that Squid mentioned is that the switcher could let you copy a page link without jumping to that page — this is an awesome quality-of-life improvement that I wouldn't have thought about by myself, and got for free.

👀 The asymmetry of product development is: users often don't notice features, and developers often don't notice bugs or inconveniences. Calls are an opportunity to fix that asymmetry. In this case, I have shown Squid a resizable sidebar and the custom links feature, and in turn he immediately found an inconvenience around custom links that I hadn't noticed before. Win-win.

🗓 Some problems need to go through stages of change before being fixed. "You don't think it's a problem" -> "you aren't sure you want to fix it" -> "you are thinking about how to fix it" -> "you are fixing it". The earlier the cycle starts, the earlier it will be done; this is why it's good to hear about problems as early as possible, even if you aren't going to do anything about them. So, I heard about a problem like that in the call: there is no distinction between done pages, in-progress pages, draft pages, etc, in Brick. I don't know what to do about it yet, but I've started thinking about it in background, and in a few months I will probably know.

Here's a round-up of what people currently use Brick for.

I don't know how well it fits any of those usecases and whether our users are happy — this is actually a good question. "Did you achieve your goals?". I don't think I will gather this kind of feedback if I don't know what to do with it, though. Once we start publishing testimonials somewhere, the case for gathering feedback will be much stronger.

📝 Writing posts. Examples: Gödel's Legacy: A game without end or A story about resource-pool. I have a ton of posts at freedom.brick.do and artyom.brick.do.

📗 Keeping public notes. Putting Twitter threads on Brick, writing daily updates on how something is going, etc. Examples: notes about everything at squid.brick.do, or technical notes at tldr.brick.do.

📒 Keeping private notes. Some people use Brick as a notebook, as a diary, or a tool for recording meeting minutes.

🌎 Personal sites. A few people have bitten the bullet and created personal sites with Brick — e.g. see Alex Yao's site.

✏️ Post drafts. Some people use Brick as a drafting tool or an equivalent of Google Docs — they write there and repost on a different site.

👔 Resumes. There are several people using Brick to write a resume — but I don't know if they have used Brick to publish it as well, or switched to something else after a while.

✅ Manuals. I have written an instruction on how to do accounting in my company in Brick. There are also people who make pages with series of screenshots like "here's a button you need to click to do X".

Long time, no updates. Everything that happened between then and now that I can remember:

⭐️ New major features — mobile support, themes, and realtime collaboration (a titanic effort by the CKEditor team — I recommend their post on how collaboration is implemented under the hood).

💰 We started charging people more! And we have ~20 paying customers now.

📈 We got an internal dashboard with metrics like "total users", "paying customers" and so on. I think it will provide a 5% boost to motivation.

☎️ We did a bunch of calls with customers, and plan to do more. They all have been helpful in some way — some were a source of additional motivation, some led to new insights about how else Brick could be used and how we should change it, and some probably made our customers like us more. At least this last point is my own secret motivation for doing calls with customers.

🤗 Related to this last point — I used Beeminder a lot in the past and I really liked how friendly they were. I want to replicate this with Brick. I want our customers to feel warm about us. One person said "I'm not sure why but I feel so much care and love for Brick in a way I don't feel about other programs" and it melted my heart.

✊ Regarding community-building, I have gotten more aggressive with inviting people to our Slack — and it turns out that people actually like being there and sometimes prefer Slack over our support chat. I hope that in a few months our Slack will grow to the point where our users will start helping each other.

🦋 One last thing — since Brick supports arbitrary HTML and publishing is super easy, people started using it for phishing. I have sent every phisher an email saying "I understand that Brick is very useful for phishing but please give us a year to grow to the point where we have enough resources to do both feature development and phishing-fighting, or we'll simply die otherwise". Phishing stopped after that.

We finished the landing page — before that, Brick didn't even have a landing page — and put it out on HN.

This brought us about ~1000 signups, four paying users the same day, and four more during the next week.

The best things about publishing Brick on Hacker News were:

• realizing that Brick is actually good enough already and we don't have to worry about it seeming amateur or "not done yet",

• and noticing that we need to make Brick much more immediately appealing — a huge percentage of the 1000 users ended up abandoning Brick without giving it a try, and so we needed to entice them to spend a bit more time with it.

I go through active, publicly available Brick pages from time to time—to see if there's anything I can help with.

I found Sathya's page where he mentioned that he's teaching children use Brick, thought "whoa", and wrote him:

Hi! I am Artyom, the co-founder of Brick.

It’s super interesting to see you using Brick for teaching!

I’d love to talk to you about what are the good/bad sides of Brick you’ve seen so far, and whether we can do anything to make it better for the teaching usecase. Happy to have a video call or do a demonstration, too.

We scheduled a call to chat about Brick—me, him, and Andrew, the Brick co-founder. Here's what I learned, sorted by impact.

THE NO-CODE COMMUNITY

Expected impact: ⭐️⭐️⭐️, will probably help a lot.

Actual impact 1.5mo later: so far haven't engaged with the no-code community at all, so there's no impact.

Sathya found out about Brick via somebody from the no-code community on Twitter. For a taste of the no-code community, see the #nocode hashtag.

I had already seen Brick tagged in #nocode posts on Twitter before, but was super skeptical about it. Something along the lines of:

"Geez, Brick is not a no-code tool, this is a writing tool. No-code is when you make an app without writing code. Brick is not for making apps".

Now that I have actually googled, it turns out that no-code is, well, anything at all that is not coding. Shopify, an e-commerce site, is no-code. Substack, a newsletter tool, is no-code. So Brick fits here. (I still have reservations, but we'll see.)

I think that having a community that is enthusiastic about trying out your product is super useful. You get active users, and you get feedback. Building without feedback sucks—both in terms of motivation and in terms of the end result's quality.

If the no-code community becomes a home for Brick, I will be happy.

PUBLIC NOTES

Expected impact: ⭐️⭐️⭐️, will probably help a lot.

Actual impact 1.5mo later: "a platform for public notes" is still how I categorize Brick in my head, and it has influenced feature development — but I'm not sure if it has helped a lot, per se. Maybe it has.

Sathya mentioned that freedom.brick.do (another site I'm writing) feels more like a wiki than like a website, and explained that in his mind Brick was more suitable for public notes than for websites—assuming that websites are things that you make with Wordpress, or with Webflow, etc.

"Public notes" is a great way to describe a potential vision for Brick, and even though I like public notes, it simply didn't occur to me before to describe Brick this way.

This might change the course of Brick. It might also help us find another community that would enjoy using Brick.

BUILDING IN PUBLIC

Expected impact: ⭐️⭐️, will probably help a lot.

Actual impact 1.5mo later: I haven't been doing this much — even publishing this page took two months! This said, this idea stuck in my head and I think eventually it will work out.

I don't remember what exactly Sathya said about building in public, but I realized that I want to be building Brick in public—this will also help with motivation and with attracting users who like Brick.

In fact, I started writing this page exactly because of that—so there is already impact.

After Brick went live, I spent a while writing posts and publishing them on Twitter — not even to promote Brick, but simply because even in the MVP state it was already better (for my needs) than anything else out there.

A friend noticed and started his own blog on Brick — and immediately subscribed to a premium plan to support us.