After building the technical prototype of my new side project I will now go ahead and plan the Minimum Viable Product (MVP).

This article shows you what parts of the project will be included in the MVP and how I am planning to implement them technically. I either show you ways of how I'll outsource it or what I will use to get the results as quickly as possible.

My main motivation is: To get rid of this overhead:

Validation through MVP

The MVP's goal is to validate the project. I think there are many ways for validating a product.

The most common ones are:

• Talking to customers
• Landing pages
• Pre-selling
• Manual processes
• MVP's

For this project, it is fairly easy to build an MVP that shows the whole functionality. Also, I want to use the project for myself so I'll definitely build it.

The MVP

What will be exactly in the MVP? I thought about nine main points that I will be working on.

1. Core Functionality (Creating Queues & Sending Requests)
2. Domain
3. Dashboard
4. Landing Page
5. Pricing
6. Authentication
7. Documentation Basics
8. Logo
9. Color Palette

Let's go through all of them and see what services I will use for that or how I will outsource it.

Core Functionality

The core functionality of the product is:

• Creating queues
• Sending requests to queues and forwarding them to the targets

All of these processes are already implemented in AWS. I showed it in greater detail in my last post.

Of course, some optimizations and smaller implementations are still needed.

What I definitely need to tackle before launching it is:

• Dead Letter queue for errors
• Saving responses & requests
• Handling idempotency

Domain

I've chosen a name and a domain for the product. 🥳

It will be serverlessq.com 🚀

I wanted to have several things on the domain:

• Emphasize serverless
• Ending with .com
• Ability to pronounce it without explaining (not like with my first product deposur)

I am very happy with the name and I think it nails the goal of the product. I bought the domain at Strato (German DNS Provider) because I've got some domains already on there and the billing is super cheap (7€ / year).

Dashboard

We need a dashboard of course. The dashboard will give the user the ability to interact with the system.

We plan to have three to four different pages.

Create Queue

First of all, we need a way of creating new queues. That means a simple form with a name to create a queue.

My Queues

Then we need an overview of all existing queues. We want to have a kind of a card layout to show some basic statistics and the URL to the queue.

Queue

Then there is the page for the details of one queue which also acts as an overview of all messages.

A message has the following items:

• ID
• Method
• Status
• Timestamp

A message also has a request and response (more in a second).

In the future this screen will also hold customization options for SQS power users. For example:

• Batch Size
• Visibility Timeout
• Redrive
• Retention period

Message Detail

The next screen shows the details of a message. A message consists of a request and a response. Both have the following attributes:

• Headers
• Body
• Status Code (only response)

With that, we can analyze calls more granularly.

Settings / Profile

Since we are adding a subscription model the user needs a way to interact with his user profile. For that, we will have a profile page and/or a settings page to customize certain things. I have no idea yet what this will look like. But it will be simple 🙂

How will we implement that?

All of this will be custom code. The tech stack will be:

• Next.js
• Tailwind CSS with Tailwind UI
• Hosted on AWS Amplify

I am very familiar with React, Amplify, Tailwind, and Next. That is why I am choosing this tech stack to implement that. We need to be very flexible that is why we want to use custom code for that and no no-code tooling.

Hosting on Amplify is for free (depending on how many users will visit the page). I've bought Tailwind UI for ~250€ but it is absolutely worth it since I will use it for the whole project.

The dashboard will live on console.serverlessq.com or app.serverlessq.com

Landing Page

The landing page is the first entry point for all users. Since I've bought Tailwind UI I will use a similar stack as for the dashboard.

However, it will be in its own folder (not a repository since we are having a monorepo structure). Since we are following a monorepo approach we will have the following subdomains in the end:

• serverlessq.com
• app.serverlessq.com
• docs.serverlessq.com
• blog.serverlessq.com

The landing page will be directly on serverlessq.com

Sections

• Hero Section -> Serverless Message Queue for Vercel Users
• Features
  • No setup is required
  • Scalable
  • No AWS knowledge
  • Build proper async processes
• Use cases (async processes, split long-running processes, performance, etc.)
• Who are we
• Pricing page

How will I implement that?

• Same tech stack as for the dashboard
• All server-side rendered for SEO

Pricing

We will also implement pricing from the beginning on.

Free Plan or Not?

I struggled a bit with the decision of including a free plan or not. I think we will integrate one. I don't see many devs who try out a product without the ability to try it out. I think it is much harder to validate when many people are using your product but not many are paying for it. However, it is definitely a good lead.

Since it is not super easy to implement free trials without a credit card in Stripe we will offer a small free plan.

There are mainly two different regulators for the price:

1. Number of queues
2. Number of requests (in general or per queue)

Long-term we can also think about multi-tenancy, SQS power users, custom alerts, and more but for now we will stick to the main two regulators.

Example pricing packages will be:

1. Free
   • 1 Queue
   • 1k Requests
2. Basic
   • 5 Queue
   • 20k Requests
3. Pro
   • Unlimited Queues
   • Unlimited Requests

I have no idea about the prices yet.

How will I implement that?

For the implementation, I will either use Stripe Checkout or Paddle.

I've used Stripe Checkout a few times already and I can copy & paste the logic easily. However, I was never really happy with that. There are so many different events to capture and I always feel uncertain about a few things.

Paddle is basically an abstraction on top of Stripe and makes things way easier. Maybe I'll give it a try this time. There is a great blog post from Luca about how to integrate Paddle into Next.js.

Authentication

Never build authentication by yourself. I strictly follow this rule and one of the bootstrappers OGs himself is still saying that:

I use Auth0 for that. We need authentication for authenticating our AppSync API, and for easy sign-up for users.

I also choose Auth0 because the sign-up and sign-in page is completely managed by them so I have less to implement. Also, social sign-ins are super easy to implement.

It will support Twitter, GitHub, and Google Login from the beginning. This is just a matter of a few clicks.

The last reason for Auth0 is I've used it a couple of times already as well. So I can use this exact implementation really easy. Speed & Security are the main factors here.

In the future, I definitely consider passwordless logins with next-auth.js.org.

How will I implement that?

• Auth0
• Next Auth0 Lib

Documentation

I want to have simple documentation on docs.serverlessq.com.

For that, I will simply use Notion or Docsaurus. This is not completely settled yet.

The goal is to explain to users how easy it is to set up a queue, and how to send requests. The second goal is also to know about new features without having explicit feature requests. Pierre had a great Twitter Threadabout validating your product and finding new feature ideas. By simply adding some feature request ideas to your documentation and tracking how many people are clicking on the links. With that it should be possible to see which feature are really needed.

Logo

I will create my logo on Fiverr. I've created one with the same seller already a couple of times. He simply needs some inspiration and you will have unlimited revisions of your logo. Will definitely do that. Cost: 15€

Color Palette

For a color palette, I think about something light and greenish. I will choose that from Daniel's cool app: colorhub.app

Timeline

I plan on finishing the whole MVP in one month. That means in the beginning of May 2022 I want to have a working prototype of message queues for Vercel.

Final Words

It is hard to validate a product. I think settling on the main functionality and trying to figure out if this will solve a real problem should be the focus.

Of course, I could also simply do a landing page and try talking to the potential users but this doesn't feel like properly validating at all.

By setting a time constraint I think it is a good way to see if we can solve a problem.

Do you have any other tips and ideas on how I could build the MVP much more efficiently? Let me know!

Do you wanna follow my journey? Follow me on Twitter