Introduction

This is a new series where I’m documenting the entire process of building my 6th SaaS product.

It’s an app that connects all the knowledge in your team and makes it super accessible:

It’s called Horizontal

In the previous issue, we talked about the Bullseye framework and discussed the “outer ring.”

Start at the core

The book Rework (written by DHH and his co-founder) starts with the chapter “Start at the Epicenter.”

Every product fundamentally solves one main problem. This is the heart of your project. This is the epicenter.

Think about tools like:

Instant messaging
File storage
Project management

What is the epicenter, the core of these tools?

For IM, it’s sending and receiving messages. You can build the world’s greatest UX, but if I cannot send a message, I won’t use your tool. If it doesn’t show me new messages, I won’t use it.

For file storage, it’s uploading and downloading files. You can provide the world’s greatest file history feature, but if upload doesn’t work, it’s a bad product.

Epicenter in action

The first time I saw this in action in a brand new product was about 2021.

I was a team lead and product manager in a smaller company, and we started a new project with a team of 5. We had a very good consultant on the project.

His first advice was to start the product with the most important feature and build it in two weeks. “Start at the epicenter,” as DHH said in the book.

So we did exactly that.

I prepared everything, created PRDs, ClickUp tasks, estimations, etc.

Then I told the team the following.

Here’s what we won’t do in the first few weeks:

Login
User management
Permissions
Error handling

Here are two things we’re going to do tomorrow:

Build the room booking feature (this was the most important feature)
Get the deployment process done

And here are two things we’re going to do 14 days from now:

Demo it to the client
Give them an MVP and ask for feedback

They were looking at me like I had lost it. And then started bombarding me with questions:

Developer: “How will they book rooms if there is no user management and login?”

Me: “We add a seeder that creates 5 demo users.”

Developer: “Does this include a CRUD for rooms and hotels, right?”

Me: “No. We add a seeder that creates 5 demo rooms.”

In the first 2 weeks, we solved their biggest problems. They had an MVP with a URL that they could play with.

Once they experienced how it feels to click around in a real system, they immediately changed some things in the requirements.

As much as I hate scrum and agile, I think something like this was the original idea.

Let’s see the agile manifesto.

Working software over comprehensive documentation – We delivered a basic but working software in 14 days. We didn’t care about documentation.

Customer collaboration over contract negotiation – Once they started using the MVP, no one cared about the “scope” of the original contract. Which was very vague by design.

Responding to change over following a plan – We had a budget. Until that was respected, we could go in any direction based on their feedback.

Individuals and interactions over processes and tools – Our entire process was that we used ClickUp. If a task is ready for code review, it should be in the “review” column. Each PR should be accepted by one developer and me.

Unfortunately, we did daily standups. I fought against it, but the consultant was very insistent on it. He was a very cool guy, I learnt a lot from him, so I stopped bitching about standups. I still have no idea what the purpose is, by the way.

So this is what agile should be, I think.

But it’s very rare to find teams like this.

The way it’s implemented in companies is horribly wrong. So I want to build a successful SaaS and never be a part of these toxic processes ever again.

The epicenter of Horizontal

This is the main flow of Horizontal:

A user registers an account
They create a team
They integrate their team’s tools, such as Drive, Slack, Jira
I download most of their data
Index it and store it in a database
Users ask questions about their content

This is the MVP.

What is the most important step?

It is clearly the last step, “Users ask questions about their content.”

This is the step that solves their problems.

So I should start with that.

But I didn’t.

Technical difficulty

There’s another criterion when it comes to selecting your first feature: technical difficulty.

Asking questions and answering them is a relatively simple RAG implementation with a few caveats. It involves chunking large text, vectorizing it, storing it, and running semantic and full-text searches with search vectors.

Here’s the important part: I’ve done this multiple times in the past.

However, I’ve never indexed terabytes worth of Google Drive or Dropbox content into one Postgres table.

I’ve already written about this in an earlier post, but here’s the challenge:

They offer 2TB for $10 and 100GB for $2.

If only five companies register with a $2 subscription, I might need to index hundreds of gigabytes of content into one database.

There are lots of techniques to solve this:

Using multiple storage layers
Prioritizing files in a “smart” way
etc

But I’m not that familiar with these.

So I started the development with indexing Google Drive. This is the most challenging integration.

I learnt this from Taylor Otwell. Start with the most difficult part of your product. If I remember correctly, he said this when he was talking about Vapor.

Depending on your project, you can choose from: