DEV Community

Cover image for Rome wasn't built in a day, and neither was my SaaS app

Posted on • Originally published at


Rome wasn't built in a day, and neither was my SaaS app

We overestimate what we can do in a week and underestimate what we can do in a year.

Building Rome

I took a week of vacation to work on my side project, Fit Vitals. I set out with the goal of "being able to onboard my first customer".

While that's technically possible right now, the product is no where near where I want it to be.

This is partially because the problem Fit Vitals solves is more complex than I originally thought. Fit Vitals enables engineers and marketers to monitor and alert on Core Web Vitals.

While that idea is simple, the complexity comes from the sheer amount of data involved.

Each pageview creates at minimum two API calls. While solving this for small sites is simple, sites that get a million views a day are more complicated.

Aaannd guess who has the budget to afford this SaaS? That's right. Sites with millions of views.

So I'm no where near finished yet.

And I'm learning that it's okay for things to take awhile.

I made progress that I'm proud of:

  • I have a great looking brand (thanks to my fiancée)
  • I'm able to process data in real time in Kinesis
  • Configured auth and a GraphQL API with AWS Amplify
  • Built an API with API Gateway
  • Prototyped an npm module for sending the analytics

That's good enough as long as I continue making progress.

I think many of us are familiar with the phrase "Rome wasn't built in a day", but James Clear added a clause to the end that makes it even more powerful.

"Rome wasn't built in a day, but they were laying bricks every hour."

In his blog post, Lay a Brick, Clear warns about using the phrase to warrant delaying action.

It's more important to lay the next brick than it is to think of the ideal finished state.


While we do solve a lot of technical problems, I'd argue our biggest challenges are mental. At least for me they are.

Here's how I'm thinking about my motivation and mental headspace while building.

Stair Step Approach

The Stair Step Approach to Bootstrapping is a framework made popular by Rob Walling back in 2015.


I think this framework solves a very important problem in the bootstrapper world – motivation.

By building a SaaS app right off of the bat, I'm trying to start on Step 3.

I'll need to be extra patient if I want to succeed.

I'm also on the lookout for a one-time product involving Core Web Vitals to help build momentum.

Start small, or at least be patient with yourself if you start big.

Building in public

I'm building Fit Vitals in public on IndieHackers.

indiehackers post

Posting about my product and getting feedback from other IndieHackers is very motivating.

Build in public, it's worth it.

Scratching your own itch

At work, I've been looking into performance monitoring for the last two months. Fit Vitals was born out of endless hours of research looking for a Web Vitals monitoring tool and finding nothing.

The first customer for this product is me.

If I make a great solution and it fixes my issues I'll be happy. Anything else is upside.

Build for yourself.

Follow along

I'm excited to continue building a profitable SaaS product in the performance monitoring space.

Instead of focusing on perfection, I'm going to work on "laying a brick" every day.

I'll be shifting my focus to starting small, building in public, and continuing to scratch my own itch.

I share almost everything I learn on Twitter.

I'm also documenting the more business-type pieces on IndieHackers.

I'll post my technical findings here.

If you prefer email you can sign up on my blog.

See you on the other side,


Top comments (0)

Timeless DEV post...

Git Concepts I Wish I Knew Years Ago

The most used technology by developers is not Javascript.

It's not Python or HTML.

It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.

I'm talking about Git and version control of course.

One does not simply learn git