The answer is multi-tenancy: an architecture where one application dynamically serves isolated experiences to many different users, often through subdomains.

In this tutorial, you'll build a multi-tenant portfolio SaaS platform from scratch using Next.js, Express, and Prisma. Each user who signs up gets their own portfolio site, served on their own subdomain — generated instantly, powered by a single backend, and stored in a single database.

Here's what you'll build:

• A landing page where users fill out a form to create their portfolio

• An Express + Prisma backend that stores each user as a "tenant"

• A Next.js middleware layer that detects subdomains and routes requests dynamically

• A JSON-driven template system that controls which sections appear on each portfolio

• A production-ready portfolio page served at name.localhost:3000 in development and name.yourdomain.com in production

You can find the complete source code in the GitHub repositories linked at the end of this tutorial.

Table of Contents

• Prerequisites

• What is Multi-Tenancy?

• How to Set Up the Backend

  • How to Install Dependencies

  • How to Configure TypeScript for ESM

  • How to Initialize Prisma

• How to Define the Prisma Schema

• How to Run Your First Migration

• How to Generate and Instantiate the Prisma Client

  • How to Generate the Client

  • How to Instantiate the Client

• How to Seed a Template

• How to Build the Express API

  • How to Install Express

  • How to Create the Server Entry Point

  • How to Create the Express App

  • How to Create the Tenant Controller

  • How to Create the Tenant Routes

  • How to Start the Server

• How to Create the Next.js Frontend

• How to Add Subdomain Routing with Middleware

• How to Build the Landing Page

  • How to Update the Layout

  • How to Create the Home Page

• How to Build the Tenant Portfolio Page

• How to Test the Full Flow

• Next Steps

• Conclusion

• Source Code

Prerequisites

Before you begin, make sure you have the following:

• Node.js (version 18 or higher) installed on your machine

• A basic understanding of React, TypeScript, and REST APIs

• Familiarity with Prisma ORM (you don't need to be an expert)

• A code editor like VS Code

You'll use Prisma Postgres as your database, so you won't need to set up a separate database server locally. Prisma handles the connection string and adapter configuration for you.

What is Multi-Tenancy?

Multi-tenancy is an architectural pattern where a single application serves multiple users — called tenants — each with isolated data and often their own URL.

Here's how the flow works in this tutorial:

1. A user visits your landing page and fills out a form with their name, bio, and skills.

2. Your Express backend creates a new tenant record in the database and generates a slug from their name.

3. The browser redirects the user to their-name.localhost:3000.

4. Your Next.js middleware detects the subdomain, extracts the slug, and rewrites the request to /tenant/their-name internally.

5. The tenant page fetches that user's data from the API and renders their portfolio.

The key insight is that the URL in the browser never changes — the rewrite is invisible to the user. One Next.js app serves every tenant dynamically.

How to Set Up the Backend

Start by creating a project folder with separate directories for the backend and frontend:

mkdir portfolio-saas && cd portfolio-saas
mkdir portfolio-api portfolio-client

Navigate into the backend directory and initialize a new Node.js project:

cd portfolio-api
npm init -y

How to Install Dependencies

Install TypeScript, Prisma, and the supporting packages:

npm install typescript tsx @types/node --save-dev
npx tsc --init
npm install prisma @types/node @types/pg --save-dev
npm install @prisma/client @prisma/adapter-pg pg dotenv

How to Configure TypeScript for ESM

Open tsconfig.json and replace its contents with:

{
  "compilerOptions": {
    "module": "ESNext",
    "moduleResolution": "bundler",
    "target": "ES2023",
    "strict": true,
    "esModuleInterop": true,
    "ignoreDeprecations": "6.0",
    "types": ["node"]
  }
}

Then open package.json and add "type": "module" to enable ESM:

{
  "type": "module"
}

How to Initialize Prisma

Run the following command to initialize Prisma and generate your schema setup:

npx prisma init --db --output ../generated/prisma

This command creates a prisma/schema.prisma file, a .env file with your database connection string, and a generated Prisma configuration folder.

How to Define the Prisma Schema

Open prisma/schema.prisma and replace its contents with the following:

generator client {
  provider = "prisma-client"
  output   = "../generated/prisma"
}

datasource db {
  provider = "postgresql"
}

model Tenant {
  id         String   @id @default(uuid())
  slug       String   @unique
  name       String
  bio        String
  skills     String[]
  templateId String
  createdAt  DateTime @default(now())
}

model Template {
  id     String @id @default(uuid())
  name   String
  config Json
}

model Post {
  id         String   @id @default(uuid())
  title      String
  content    String
  tenantSlug String
  createdAt  DateTime @default(now())
}

Let's look at what each model does.

The Tenant model represents a user who has signed up and created a portfolio. The slug field is generated from their name (for example, "John Doe" becomes john-doe) and is used as their subdomain. The templateId links each tenant to a template that controls their portfolio's layout.

The Template model stores layout configuration as JSON. Instead of hardcoding sections like "hero" or "skills" into your components, you store them in the database. This means you can add or remove sections for different templates without touching any component code.

The Post model is included for future extensibility — you can use it to let tenants publish blog posts on their portfolio.

How to Run Your First Migration

Run the following command to create your database tables based on the schema:

npx prisma migrate dev --name init

This command creates the database tables, generates a migration file, and applies the migration to your database. After it runs, your Postgres database structure matches your Prisma schema exactly.

How to Generate and Instantiate the Prisma Client

How to Generate the Client

Run this command to generate a fully type-safe Prisma Client based on your schema:

npx prisma generate

You only need to run this once after each schema change. The generated client lives in the ../generated/prisma folder you configured earlier.

How to Instantiate the Client

Create a new file at lib/prisma.ts and add the following:

import 'dotenv/config';
import { PrismaPg } from '@prisma/adapter-pg';
import { PrismaClient } from '../generated/prisma/client';

const connectionString = process.env.DATABASE_URL as string;

const adapter = new PrismaPg({ connectionString });
const prisma = new PrismaClient({ adapter });

export default prisma;

This file creates a single shared Prisma Client instance that your entire backend will import. The PrismaPg adapter connects Prisma to your Postgres database using the connection string from your .env file.

How to Seed a Template

Your platform needs at least one template in the database before any tenant can sign up. Instead of hardcoding layout decisions into your components, you'll store the template configuration as JSON and read it at runtime.

Create a new file at prisma/seed.ts and add the following:

import prisma from '../lib/prisma';

async function main() {
  await prisma.template.create({
    data: {
      name: 'minimal',
      config: {
        theme: {
          primaryColor: '#6366f1',
          background: 'dark',
        },
        sections: {
          hero: true,
          about: true,
          skills: true,
          projects: true,
          blog: true,
          contact: true,
        },
      },
    },
  });

  console.log('Template seeded successfully.');
}

main()
  .catch((e) => {
    console.error(e);
    process.exit(1);
  })
  .finally(async () => {
    await prisma.$disconnect();
  });

The config field is stored as JSON in Postgres. When a tenant's portfolio loads, your frontend reads this JSON to decide which sections to show. Setting hero: false on a template would hide the hero section for every tenant using that template — no code changes needed.

Now add a seed script to your package.json:

{
  "scripts": {
    "seed": "tsx prisma/seed.ts"
  }
}

Run it:

npm run seed

Your database now has a default template ready to attach to new tenants.

How to Build the Express API

Now you'll build the backend API that creates tenants and retrieves their data.

How to Install Express

npm install express cors
npm install -D @types/express @types/cors

How to Create the Server Entry Point

Create src/index.ts:

import app from './app';

const PORT = 8080;

app.listen(PORT, () => {
  console.log('Server is running on port 8080');
});

How to Create the Express App

Create src/app.ts:

import express from 'express';
import cors from 'cors';
import tenantRoutes from './routes/tenant.routes';

const app = express();

app.use(cors());
app.use(express.json());
app.use('/api', tenantRoutes);

export default app;

This file sets up CORS so your Next.js frontend can communicate with the API, parses JSON request bodies, and mounts all tenant routes under the /api prefix.

How to Create the Tenant Controller

Create src/controllers/tenant.controller.ts:

import { Request, Response } from 'express';
import prisma from '../../lib/prisma';

export async function createTenant(req: Request, res: Response) {
  const { name, bio, skills } = req.body;

  if (!name || !bio || !skills) {
    return res.status(400).json({ error: 'Missing required fields' });
  }

  const slug = name.toLowerCase().replace(/\s+/g, '-');

  const template = await prisma.template.findFirst();
  if (!template) {
    return res.status(500).json({ error: 'No template found' });
  }

  const tenant = await prisma.tenant.create({
    data: {
      slug,
      name,
      bio,
      skills,
      templateId: template.id,
    },
  });

  res.json({ slug: tenant.slug });
}

export async function getTenant(req: Request, res: Response) {
  const slug = req.params.slug;

  if (!slug || typeof slug !== 'string') {
    return res.status(400).json({ error: 'Invalid slug parameter' });
  }

  const tenant = await prisma.tenant.findUnique({
    where: { slug },
  });

  if (!tenant) {
    return res.status(404).json({ error: 'Tenant not found' });
  }

  const template = await prisma.template.findUnique({
    where: { id: tenant.templateId },
  });

  res.json({ tenant, template });
}

Let's break down what this controller does.

createTenant takes the user's name, bio, and skills from the request body. It generates a slug by lowercasing the name and replacing spaces with hyphens — so "Jane Smith" becomes jane-smith. It then finds the first available template and creates the tenant record in the database, linking the template to the new tenant via templateId.

getTenant looks up a tenant by their slug and also fetches the template attached to them. Both pieces of data are returned together so the frontend can render the portfolio and apply the correct layout configuration in a single API call.

How to Create the Tenant Routes

Create src/routes/tenant.routes.ts:

import { Router } from 'express';
import { createTenant, getTenant } from '../controllers/tenant.controller';

const router = Router();

router.post('/tenants', createTenant);
router.get('/tenants/:slug', getTenant);

export default router;

Your API now exposes two endpoints:

POST   /api/tenants        — creates a new tenant
GET    /api/tenants/:slug  — retrieves a tenant and their template

How to Start the Server

Add the dev script to your package.json:

{
  "scripts": {
    "dev": "tsx watch src/index.ts",
    "seed": "tsx prisma/seed.ts"
  }
}

Run it:

npm run dev

You should see Server is running on port 8080 in your terminal. Your backend is ready.

How to Create the Next.js Frontend

Navigate to the portfolio-client directory and create a new Next.js project. Make sure to select Yes when the installer asks if you want to use Tailwind CSS:

cd ../portfolio-client
npx create-next-app@latest . --typescript --app --tailwind --eslint
npm install

Since create-next-app sets up Tailwind for you automatically, no extra configuration is needed. The tailwind.config.ts and the @tailwind directives in globals.css are already in place.

How to Add Subdomain Routing with Middleware

This is the heart of the multi-tenant architecture. You need a piece of code that runs before every request, reads the subdomain from the URL, and rewrites the request to the correct internal route — all without the user ever seeing the URL change.

Create a file called proxy.ts in the root directory:

import { NextRequest, NextResponse } from 'next/server';

export function proxy(request: NextRequest) {
  const { pathname } = request.nextUrl;
  const host = request.headers.get('host') ?? '';

  const hostname = host.split(':')[0];
  const parts = hostname.split('.');

  // Local development: john.localhost:3000
  if (hostname.endsWith('localhost')) {
    const subdomain = parts[0];

    // Root localhost — load the landing page normally
    if (subdomain === 'localhost') {
      return NextResponse.next();
    }

    // Already rewritten — don't rewrite again
    if (pathname.startsWith('/tenant')) {
      return NextResponse.next();
    }

    return NextResponse.rewrite(new URL(`/tenant/${subdomain}`, request.url));
  }

  // Production: john.yourdomain.com
  if (parts.length > 2) {
    const subdomain = parts[0];

    if (subdomain !== 'www') {
      if (pathname.startsWith('/tenant')) {
        return NextResponse.next();
      }

      return NextResponse.rewrite(new URL(`/tenant/${subdomain}`, request.url));
    }
  }

  return NextResponse.next();
}

export const config = {
  matcher: [
    '/((?!_next/static|_next/image|favicon.ico|robots.txt|sitemap.xml).*)',
  ],
};

Here's exactly what this proxy does, step by step.

It reads the host header from every incoming request and splits it on . to extract the subdomain. For a request to john.localhost:3000, the subdomain is john. For a request directly to localhost:3000, the subdomain is localhost itself — in which case the proxy lets the request through unchanged so the landing page loads normally.

When a subdomain is detected, the proxy rewrites the request URL from / to /tenant/john internally. This rewrite is invisible to the browser — the user still sees john.localhost:3000 in their address bar, but Next.js routes the request to your /tenant/[slug] page.

The if (pathname.startsWith('/tenant')) guard prevents infinite rewrite loops. Without it, the already-rewritten request would be rewritten again on the next pass through the middleware.

How to Build the Landing Page

How to Update the Layout

Open app/layout.tsx and update it:

import type { Metadata } from 'next';
import { Geist, Geist_Mono } from 'next/font/google';
import './globals.css';

const geistSans = Geist({
  variable: '--font-geist-sans',
  subsets: ['latin'],
});

const geistMono = Geist_Mono({
  variable: '--font-geist-mono',
  subsets: ['latin'],
});

export const metadata: Metadata = {
  title: 'Portfolio SaaS App',
  description: 'Create and host your portfolio with subdomains',
};

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body className={`\({geistSans.variable} \){geistMono.variable} antialiased`}>
        {children}
      </body>
    </html>
  );
}

How to Create the Home Page

Create app/page.tsx:

'use client';

import { useState } from 'react';

export default function Home() {
  const [name, setName] = useState('');
  const [bio, setBio] = useState('');
  const [skills, setSkills] = useState('');

  const handleSubmit = async () => {
    const res = await fetch('http://localhost:8080/api/tenants', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        name,
        bio,
        skills: skills.split(',').map((s) => s.trim()),
      }),
    });

    const data = await res.json();
    window.location.href = `http://${data.slug}.localhost:3000`;
  };

  return (
    <div className="min-h-screen bg-gradient-to-br from-slate-900 to-slate-800 text-white flex flex-col">
      {/* Header */}
      <header className="flex items-center justify-between px-10 py-5">
        <span className="text-xl font-semibold tracking-wide">PortfolioSaaS</span>
        <nav className="flex gap-6 text-sm text-slate-400">
          <a href="#features" className="hover:text-white transition-colors">Features</a>
          <a href="#pricing" className="hover:text-white transition-colors">Pricing</a>
          <a href="#docs" className="hover:text-white transition-colors">Docs</a>
        </nav>
      </header>

      {/* Main */}
      <main className="flex flex-1 items-center justify-center px-6 py-10">
        <div className="w-full max-w-md bg-slate-800 rounded-2xl p-10 shadow-2xl">
          <h1 className="text-3xl font-bold mb-3">Create Your Portfolio</h1>
          <p className="text-slate-400 text-sm mb-8">
            Launch your personal portfolio instantly with your own subdomain.
          </p>

          <input
            type="text"
            placeholder="Your Name"
            onChange={(e) => setName(e.target.value)}
            className="w-full bg-slate-900 border border-slate-700 rounded-lg px-4 py-3 text-sm text-white placeholder-slate-500 focus:outline-none focus:border-indigo-500 mb-4"
          />

          <textarea
            placeholder="Short Bio"
            rows={4}
            onChange={(e) => setBio(e.target.value)}
            className="w-full bg-slate-900 border border-slate-700 rounded-lg px-4 py-3 text-sm text-white placeholder-slate-500 focus:outline-none focus:border-indigo-500 mb-4 resize-none"
          />

          <input
            type="text"
            placeholder="Skills (comma separated)"
            onChange={(e) => setSkills(e.target.value)}
            className="w-full bg-slate-900 border border-slate-700 rounded-lg px-4 py-3 text-sm text-white placeholder-slate-500 focus:outline-none focus:border-indigo-500 mb-6"
          />

          <button
            onClick={handleSubmit}
            className="w-full bg-indigo-600 hover:bg-indigo-500 text-white font-semibold py-3 rounded-lg transition-colors"
          >
            Create Portfolio
          </button>
        </div>
      </main>

      {/* Footer */}
      <footer className="text-center text-xs text-slate-500 py-5 border-t border-slate-800">
        © {new Date().getFullYear()} PortfolioSaaS. All rights reserved.
      </footer>
    </div>
  );
}

When a user submits the form, three things happen in sequence. First, a POST request creates a new tenant in your database. Second, the API returns the generated slug. Third, the browser redirects the user to their subdomain — their-name.localhost:3000 — where the middleware takes over and renders their portfolio.

How to Build the Tenant Portfolio Page

Create app/tenant/[slug]/page.tsx:

import type { Metadata } from 'next';

async function getTenant(slug: string) {
  const res = await fetch(`http://localhost:8080/api/tenants/${slug}`, {
    cache: 'no-store',
  });
  return res.json();
}

export async function generateMetadata({
  params,
}: {
  params: Promise<{ slug: string }>;
}): Promise<Metadata> {
  const { slug } = await params;
  const { tenant } = await getTenant(slug);

  if (!tenant) {
    return {
      title: 'Portfolio Not Found',
      description: 'This portfolio does not exist.',
      robots: { index: false, follow: false },
    };
  }

  return {
    title: tenant.name,
    description:
      tenant.bio?.slice(0, 160) ||
      `Explore ${tenant.name}'s professional portfolio.`,
    openGraph: {
      title: tenant.name,
      description: tenant.bio,
      type: 'website',
    },
  };
}

function initials(name: string) {
  return name
    .split(' ')
    .filter(Boolean)
    .slice(0, 2)
    .map((n) => n[0]?.toUpperCase())
    .join('');
}

export default async function TenantPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const data = await getTenant(slug);

  const tenant = data?.tenant;
  const template = data?.template;

  if (!tenant) {
    return (
      <div className="min-h-screen bg-slate-900 text-white flex items-center justify-center">
        <h1 className="text-2xl font-bold text-slate-400">Portfolio not found</h1>
      </div>
    );
  }

  const primary = template?.config?.theme?.primaryColor || '#6366f1';

  // Template-driven section toggles with safe defaults
  const sections = {
    hero: true,
    about: true,
    skills: true,
    projects: true,
    blog: true,
    contact: true,
    ...(template?.config?.sections ?? {}),
  };

  const avatarUrl = tenant.avatarUrl as string | undefined;

  return (
    <div className="min-h-screen bg-gradient-to-br from-slate-900 via-slate-800 to-slate-900 text-slate-100">

      {/* Header */}
      <header className="sticky top-0 z-20 backdrop-blur-md bg-slate-900/60 border-b border-white/5">
        <div className="max-w-5xl mx-auto px-5 py-4 flex items-center justify-between gap-4">
          <div className="flex items-center gap-3 min-w-0">
            <span
              className="w-2.5 h-2.5 rounded-full shrink-0"
              style={{ backgroundColor: primary }}
            />
            <span className="font-semibold truncate">{tenant.name}</span>
          </div>

          <nav className="hidden md:flex items-center gap-5 text-sm text-slate-400">
            {(sections.hero || sections.about) && (
              <a href="#about" className="hover:text-white transition-colors">About</a>
            )}
            {sections.skills && (
              <a href="#skills" className="hover:text-white transition-colors">Skills</a>
            )}
            {sections.projects && (
              <a href="#projects" className="hover:text-white transition-colors">Projects</a>
            )}
            {sections.blog && (
              <a href="#blog" className="hover:text-white transition-colors">Blog</a>
            )}
            {sections.contact && (
              <a href="#contact" className="hover:text-white transition-colors">Contact</a>
            )}
          </nav>

          {sections.contact && (
            <a
              href="#contact"
              className="text-sm font-semibold px-4 py-2 rounded-full transition-transform hover:-translate-y-px"
              style={{ backgroundColor: primary, color: '#0b1020' }}
            >
              Hire me
            </a>
          )}
        </div>
      </header>

      {/* Hero / About */}
      {(sections.hero || sections.about) && (
        <section className="px-5 pt-20 pb-14" id="about">
          <div className="max-w-5xl mx-auto bg-white/[0.04] border border-white/[0.08] rounded-2xl p-7 shadow-2xl grid grid-cols-[110px_1fr] gap-6 items-center">

            {/* Avatar */}
            <div className="w-[110px] h-[110px] rounded-full overflow-hidden border border-white/10 bg-white/5 flex items-center justify-center shrink-0">
              {avatarUrl ? (
                // eslint-disable-next-line @next/next/no-img-element
                <img src={avatarUrl} alt={`${tenant.name} avatar`} className="w-full h-full object-cover" />
              ) : (
                <span className="text-2xl font-extrabold text-slate-200 tracking-tight">
                  {initials(tenant.name)}
                </span>
              )}
            </div>

            {/* Text */}
            <div className="min-w-0">
              <h1
                className="text-5xl font-extrabold tracking-tight leading-tight mb-3"
                style={{ color: primary }}
              >
                {tenant.name}
              </h1>
              <p className="text-slate-400 text-base leading-relaxed max-w-2xl">
                {tenant.bio}
              </p>
              <div className="flex flex-wrap gap-3 mt-5">
                {sections.contact && (
                  <a
                    href="#contact"
                    className="inline-flex items-center px-5 py-2.5 rounded-full text-sm font-semibold transition-transform hover:-translate-y-px"
                    style={{ backgroundColor: primary, color: '#0b1020' }}
                  >
                    Let&apos;s connect
                  </a>
                )}
                {sections.skills && (
                  <a
                    href="#skills"
                    className="inline-flex items-center px-5 py-2.5 rounded-full text-sm font-semibold text-slate-200 border border-white/10 bg-white/5 hover:border-white/20 transition-all hover:-translate-y-px"
                  >
                    View skills
                  </a>
                )}
              </div>
            </div>
          </div>
        </section>
      )}

      {/* Skills */}
      {sections.skills && (
        <section className="px-5 py-14 max-w-5xl mx-auto" id="skills">
          <h2 className="text-2xl font-bold text-center tracking-tight mb-7">Skills</h2>
          <div className="flex flex-wrap gap-3 justify-center">
            {tenant.skills.map((skill: string) => (
              <span
                key={skill}
                className="px-4 py-2 rounded-full text-sm font-semibold bg-white/5 backdrop-blur-sm hover:-translate-y-0.5 hover:shadow-lg transition-all"
                style={{ border: `1px solid ${primary}` }}
              >
                {skill}
              </span>
            ))}
          </div>
        </section>
      )}

      {/* Projects */}
      {sections.projects && (
        <section className="px-5 py-14 max-w-5xl mx-auto" id="projects">
          <h2 className="text-2xl font-bold text-center tracking-tight mb-7">Projects</h2>
          <div className="flex flex-wrap gap-3 justify-center">
            {['Portfolio SaaS', 'Multi-tenant Routing', 'Template Builder'].map((p) => (
              <span
                key={p}
                className="px-4 py-2 rounded-full text-sm font-semibold bg-white/5 backdrop-blur-sm hover:-translate-y-0.5 hover:shadow-lg transition-all"
                style={{ border: `1px solid ${primary}` }}
              >
                {p}
              </span>
            ))}
          </div>
        </section>
      )}

      {/* Blog */}
      {sections.blog && (
        <section className="px-5 py-14 max-w-5xl mx-auto" id="blog">
          <h2 className="text-2xl font-bold text-center tracking-tight mb-7">Blog</h2>
          <div className="flex flex-wrap gap-3 justify-center">
            {[
              'How I built this portfolio',
              'Next.js Middleware Tips',
              'Designing Templates',
            ].map((post) => (
              <span
                key={post}
                className="px-4 py-2 rounded-full text-sm font-semibold bg-white/5 backdrop-blur-sm hover:-translate-y-0.5 hover:shadow-lg transition-all"
                style={{ border: `1px solid ${primary}` }}
              >
                {post}
              </span>
            ))}
          </div>
        </section>
      )}

      {/* Contact */}
      {sections.contact && (
        <section className="px-5 pt-2 pb-16" id="contact">
          <div className="max-w-3xl mx-auto bg-white/[0.04] border border-white/[0.08] rounded-2xl p-7">
            <h2 className="text-xl font-bold mb-2">Contact</h2>
            <p className="text-slate-400 leading-relaxed mb-5">
              Want to work together? Send a message and I&apos;ll reply quickly.
            </p>
            <div className="flex flex-wrap gap-3">
              <a
                href={`mailto:hello@${tenant.slug}.com`}
                className="inline-flex items-center px-5 py-2.5 rounded-full text-sm font-semibold transition-transform hover:-translate-y-px"
                style={{ backgroundColor: primary, color: '#0b1020' }}
              >
                Email me
              </a>
              <a
                href="#about"
                className="inline-flex items-center px-5 py-2.5 rounded-full text-sm font-semibold text-slate-200 border border-white/10 bg-white/5 hover:border-white/20 transition-all hover:-translate-y-px"
              >
                Back to top
              </a>
            </div>
          </div>
        </section>
      )}

      {/* Footer */}
      <footer className="text-center text-xs text-slate-500 py-5 border-t border-white/5">
        © {new Date().getFullYear()} {tenant.name}
      </footer>
    </div>
  );
}

There are a few important details in this page worth calling out.

The generateMetadata function runs server-side before the page renders and sets the page title, description, and Open Graph tags for each tenant individually. This means every portfolio gets its own SEO metadata — important for a real SaaS product.

The sections object merges safe defaults (hero: true, skills: true, and so on) with whatever the tenant's template specifies. This means even if the template JSON is missing a key, the page won't break — the section will simply fall back to being shown.

The initials helper generates a two-letter avatar placeholder from the tenant's name when no profile image is available. "Jane Smith" produces "JS" — a small detail that makes the portfolio look polished even before a user adds a photo.

Notice that the primary color from the template JSON (theme.primaryColor) is applied using the style prop rather than a Tailwind class. This is intentional. Tailwind generates class names at build time and cannot know the dynamic color value stored in your database. Inline styles are the correct approach whenever a CSS value is truly dynamic.

How to Test the Full Flow

Start both servers in separate terminal windows:

# Terminal 1 — Backend
cd portfolio-api
npm run dev

# Terminal 2 — Frontend
cd portfolio-client
npm run dev

Now test the complete flow:

1. Visit http://localhost:3000 and fill out the form with your name, a short bio, and a comma-separated list of skills.

2. Click Create Portfolio. The form submits to your Express API, which creates the tenant record and returns the slug.

3. Your browser redirects to http://your-name.localhost:3000.

4. The Next.js middleware detects the subdomain, rewrites the request to /tenant/your-name, and your portfolio page fetches and renders your data.

You should see a fully rendered portfolio page with your name, bio, skills, and the placeholder projects and blog sections — all styled with Tailwind utility classes.

Next Steps

You now have a working multi-tenant SaaS foundation. Here are some extensions worth considering for a production build:

You could add authentication with NextAuth.js so tenants can log in and update their portfolio without losing their data between sessions.

You could also add custom domain support so tenants can point their own domain (for example, janedoe.com) to their portfolio by adding a CNAME record. You would need to handle wildcard SSL certificates on your hosting provider.

You could add image uploads for avatars using Cloudinary or AWS S3, then store the URL in the tenant record and replace the initials fallback with a real photo.

You could add real blog post management using the Post model already defined in your schema. Tenants could write and publish posts that appear on their portfolio.

And you could add Stripe subscriptions so tenants pay a monthly fee to keep their portfolio live. The architecture from the Stripe Connect tutorial maps directly onto this.

Finally, you could deploy the backend to Railway or Render and the frontend to Vercel. Just make sure to update your API URLs from localhost:8080 to your production URL before deploying.

Conclusion

In this tutorial, you built a complete multi-tenant SaaS platform where users can sign up, get their own subdomain, and have a portfolio site generated instantly — all from a single codebase.

You learned how to use Next.js middleware to detect subdomains and rewrite requests dynamically, model multi-tenant data in Prisma with a slug-based routing system, build a JSON-driven template system that controls page layout without code changes, and style a production-ready Next.js frontend entirely with Tailwind CSS utility classes.

The core insight is that multi-tenancy isn't magic. It's subdomain detection plus dynamic routing plus isolated data. Once you understand those three moving parts, you can apply this pattern to any SaaS product you build.

If you found this tutorial helpful, share it with someone who is learning to build full-stack applications. Happy coding!

Source Code

You can find the complete source code for both parts of this project on GitHub:

• Frontend (Next.js multi-tenant app) + Backend (Express + Prisma API): https://github.com/michaelokolo/portfolio-saas-v1

Getting those first few users can feel like climbing a mountain. It’s the hardest part, but also the most important. Without customers, your SaaS doesn’t grow.

Without feedback from real users, you can’t improve. And let’s be honest – seeing people pay for your product is a huge motivation boost.

I’ve seen this challenge many times, and I know the pressure is real. That’s why I’m breaking it all down in the simplest way possible. No confusing words, no vague advice – just a clear plan you can use.

Let’s jump right in.

Why Getting Your First SaaS Customers Matters So Much

Before we talk strategy, let’s be super clear about why the first customers are gold:

• They validate your idea. If strangers are willing to pay, you’re onto something real.

• They help you shape the product. Early users are honest about what works and what’s broken.

• They fuel your momentum. A few early wins can give you the confidence to keep pushing forward.

• They help you spread the word. Happy first customers are often your best marketers.

Your first ten customers matter more than your next hundred. So it’s worth taking the time to get this right.

Real Ways to Get Your First SaaS Customers

1. Start With People You Know

Don’t be shy to reach out to friends, family, former coworkers, and old clients. Tell them about your new SaaS and ask if they know anyone who might need it.

And remember: you’re not begging – you’re offering something valuable.

Pro Tip: Focus on the people they know, not just whether they want to buy themselves.

2. Join Communities Where Your Customers Hang Out

Find Facebook groups, Reddit forums, Slack communities, or LinkedIn groups where your ideal users already spend time.

Be helpful. Answer questions. Join conversations. Build trust. Then, when it’s natural, mention your product.

Real Example: If you built a tool for yoga instructors, find Facebook groups for yoga teachers.

3. Launch on Product Hunt

Product Hunt is full of early adopters looking for new tools.

If you do a good launch (with a nice-looking page, clear description, and a bit of buzz on the side), you could get your first few hundred signups in one day.

Helpful read: How to Launch on Product Hunt Successfully

4. Offer a “Beta” Version

Invite early users to test your software before the official launch.
Make it feel special – they get early access, and their feedback will shape the product.

Bonus Tip: Beta users are often more forgiving about bugs. They expect a few rough edges.

5. Use Cold Outreach (But Do It Right)

Sending emails to strangers sounds scary. But if you write short, respectful, personalized emails, it works.
Focus on how you can solve a real problem they have – not on how great your product is.

Good Cold Email Example:

"Hi [Name],
I noticed you [specific detail]. I built a tool that might save you [X hours / $X per month].
Would you like me to send a quick demo?"

Keep it about them, not you.

6. Get Active on LinkedIn

Post helpful tips, mini case studies, and personal stories. Show people you understand their struggles.
It builds trust. It shows you’re serious. And it keeps you top-of-mind when someone does need your product.

7. Partner With Other Small Businesses

Find companies that serve the same audience but aren’t direct competitors.

Maybe you made a booking app for barbershops. You could partner with a payment processor or marketing agency that also targets barbers.

Offer a referral deal or co-host a webinar together.

8. Content Marketing (Start Small)

You don’t need a full blog with 50 articles right away. Start with 2–3 simple, super-useful blog posts that answer real questions your customers have.

Example:

If you built an invoicing tool, write posts like:

• “How to Send Your First Invoice as a Freelancer”

• “5 Mistakes New Freelancers Make With Payments”

Helpful Link: Beginner’s Guide to Content Marketing

9. Run a Tiny Paid Ad Test

A small Facebook or Google ad campaign (even $5–10 a day) can give you quick feedback.

Target very specifically – not just "small business owners," but "independent yoga teachers in New York."

Watch which messages work, which don’t, and adjust fast.

10. Create Simple Case Studies

Even if you only have one early customer, ask them if you can tell their story. How they used your product. What problem it solved. What results they saw.

Nothing builds trust faster than real success stories.

11. Offer a Founder's Deal

Offer lifetime discounts or special plans to your first customers. This rewards them for taking a chance on you early, and it creates urgency (“only 20 spots left!”).

Example: Lifetime access for $99 instead of $20/month.

12. Make It Ridiculously Easy to Share

Add a simple “Share with a friend” button in your app, emails, and thank-you pages. Happy users want to help – just make it easy for them.

FAQs

Should I offer my SaaS for free at first?

I would recommend a free trial instead of free forever. Free users are often less serious. You want customers who see value and are willing to pay for it.

How long does it usually take?

Honestly? It depends. Some people land their first customers in a week. Others need a few months. Stay patient and keep improving both your product and your outreach.

What if no one seems interested?

It happens. If you're hearing crickets, it might be time to talk directly to potential customers, ask more questions, and tweak your offer. Sometimes it’s just a positioning problem.

Final Thoughts

Getting your first SaaS customers isn’t about being perfect. It’s about getting real people to trust you enough to give your product a shot. Start small. Talk to people. Solve real problems.

And keep improving a little every day.

If you need a hand with SaaS marketing or growing your idea, I’m always happy to connect. You can find me on X at x.com/_udemezue, or check out my portfolio: Udemezue.pages.dev.

Further Resources

If you want to dive deeper, check out:

• The Mom Test (book) — How to talk to customers and get honest feedback.

• Indie Hackers — A community where founders share how they got their first users.

• First 1000 Users Guide (from Demand Curve) — Very detailed but still easy to follow.

Imagine a feature that promises to enhance user experience but that ends up resonating with only a small subset of users. This scenario underscores the importance of precision in feature rollouts.

Fortunately, feature flagging management tools like Flagsmith can help with granular segmentation. This process helps your team make sure that new features are introduced to the most relevant audiences. Granular Segmentation makes it easier to understand your user base, leading to higher engagement and satisfaction.

In this article, we will be focusing on the concept of granular user segmentation and its significance in enhancing feature rollouts. We’ll also explore some best practices, pitfalls to avoid, and will look at how Flagsmith facilitates granular segmentation with feature flags.

Here’s what we’ll cover:

1. What is Flagsmith?

2. What is Granular Segmentation?

3. How Feature Flags Enable Granular Segmentation?

4. How to Implement Granular Segmentation in Flagsmith

5. Benefits of Granular Segmentation for User Engagement

6. Conclusion

What is Flagsmith?

Flagsmith is an open-source feature management platform that helps teams control feature rollouts with precision. It helps developers toggle features on or off for specific users, environments, or groups without redeploying code.

Ideal for A/B testing, phased rollouts, and remote configuration, Flagsmith ensures real-time adjustments and seamless feature delivery. With flexible deployment options – hosted, private cloud, or on-premises – it adapts to the needs of organizations of all sizes.

The Importance of Granular Segmentation

What is Granular Segmentation?

Granular segmentation is a process in which the user base is divided into groups based on unique attributes such as behavior demographics or engagement levels. These groups can be identified as segments of users of a platform, and each segment is based on several traits that help teams tailor feature rollouts to meet the needs of each segment.

This granular level of control over rollouts helps product teams release features that resonate with their user base. This creates a more personalized experience for the end user that can improve the effectiveness of the feature.

Now, let’s discuss what kind of an impact feature rollouts might have.

Impact of Feature Rollouts

The advantages of granular segmentation in feature rollouts include:

• Targeted relevance: Features are delivered to users who will benefit most from them, making the updates more relevant and useful. This targeted approach increases the likelihood of user engagement.

• Optimized user experience: Because of this targeted approach, businesses can prevent rollouts of features that overwhelm their users in any way. This means that users would receive updates according to their interests, leading to a better user experience.

• Higher adoption rates: All this would also lead to higher adoption rates. An increased adoption rate is a sign of good engagement from a business’s users as well as of business growth

• Less risk when rolling out new features: Segmenting your user base and releasing new features to, say, a select 10% of users reduces risk. Teams can see how features do with those users and adjust accordingly before rolling out to the next segment. Or they can roll back if the impact is negative, which helps them avoid incidents like the latest high-publicity one we saw with CrowdStrike.

To put things into perspective, let’s discuss an example of an e-commerce store.

The MART Example

The MART is an online store that sells various products. They want to introduce an AI-powered recommendation engine, but only to a subset of their user base that shows less engagement on the platform buying products. AI-powered recommendation engines would target this user segment to generate more sales from the platform and increase business growth.

Here we see the concept of segmentation in practice where a feature is dedicatedly exposed to a user group's explicit attributes, thus leading to increased relevance and user satisfaction.

If the feature proves to be successful with the targeted segment, the next phase would be to expand its availability to other user groups.

How Feature Flags Enable Granular Segmentation

You can integrate Flagsmith into your development workflow by using SDKs. The user segmentation adds a layer of granular control to the product teams with over-feature releases. This control helps product teams to minimize the risk of degradation of a new feature. They can leverage the GUI to interact with Flagsmith and roll out/roll back features according to their needs.

What are Segments in Feature Rollouts?

A segment is a subset of identities, defined by a set of rules based on traits associated with identities. So a single identity can be a part of many segments and is associated with an environment, such as staging or production.

You might be wondering – how can product teams use segments in their feature rollouts?

You can use segments to create ‘overrides’ on any number of features in your application. This allows you to control the state and/or value of a feature for a selection of your users, as defined by the segment.

Now that you understand segments, let’s discuss what key features allow you to use detailed user segmentation.

• User attributes: Flagsmith allows you to define and manage user attributes, such as location, behavior, subscription levels, or platform activity. These are attributes you can use to create highly specific user segments.

• Segment definitions: You can create custom segment definitions from these user attributes. For instance, you can define a segment for users who have been highly active on the platform since last month or users who live in a different region than most of your user base. This granularity ensures that you can target features to the most relevant user groups.

• Dynamic targeting: Dynamic targeting can help you adjust feature rollouts on the basis of user attributes. This means that you can progressively roll out features to segments of users, monitor their performance, and make adjustments to the feature accordingly.

Flexibility and Control

Flexibility and control are a rare combination when it comes to such tools, but with Flagsmith you get the best of both worlds. User segments and feature management ensure you have precision and control over your feature rollouts:

• Granular control: Multiple segment creation and control access are available in Flagsmith with a variety of criteria, allowing feature rollouts that cater to specific user needs.

• Analytics and feedback: Analytics and feedback are an integral part of the feature testing loop. They provide tracking of how different segments interact with new features. It’s invaluable for understanding the user’s behavior on the platform which helps you make informed decisions for further rollouts.

So now you’ve learned what segments are, what you can do with them, and how segments help in granular control over rollouts. Now, let’s move on and see how you can implement segmentation using Flagsmith.

How to Implement Granular Segmentation in Flagsmith

Set Up Flagsmith in Your Project

You can integrate Flagsmith into your application using the available SDKs for the language of your choice. For example, to integrate the SDK in Node.js, you’ll first need to install the npm package as follows:

npm i flagsmith-nodejs --save

After installing the package, you will use the following code to initialize Flagsmith in your project:

const Flagsmith = require('flagsmith-nodejs');
const flagsmith = new Flagsmith({ environmentKey: 'FLAGSMITH_SERVER_SIDE_ENVIRONMENT_KEY',});

Once it’s integrated, configure your Flagsmith instance by creating a new project. We’ll go through this below.

How to Create Identities and Define User Traits and Segments

Now you’ll need to create the identities and traits you want to use for segmentation. These could include user profile information, behavior metrics, or any other relevant data.

So, let’s create a user named John Doe.

Now click on the created user and define a trait country.

In Flagsmith, creating a trait country involves defining a user attribute that specifies their geographic location. Traits are key-value pairs assigned to user identities, allowing for precise segmentation. For example, you can define the "country" trait with values like "USA," "Canada," or "Germany."

This enables product teams to create segments based on location and target feature rollouts accordingly. For instance, a feature can be activated only for users with the "country" trait set to "USA," facilitating controlled and region-specific rollouts.

Next, you’ll create some segments. You’ll use the Flagsmith dashboard to create custom segments based on these attributes. For example, you can create a segment for users who are from the USA. Define your segment, for example (western_users ), as below:

How to Create and Manage Feature Flags

Create a feature flag called ai_recommendation_engine in Flagsmith for the features you want to roll out. Each flag represents a specific feature or configuration option that can be toggled on or off.

Next, assign your feature flags to the segment you created. For instance, if you have a recommendation engine, you can target it specifically to users that match the segment created in the previous step. Use the Flagsmith dashboard to set these targeting rules and manage feature flag settings.

How to Target Segments for Rollouts

After configuring Flagsmith and setting up your segments and traits, you can start rolling out features to your defined segments.

First, you’ll want to do gradual rollouts. Using the percentage split operator, you can initially release the feature to a small percentage of users within the segment. Based on performance and feedback, you can gradually expand the rollout to a larger portion of the segment or additional segments, ensuring a controlled and data-driven approach.

Second, monitoring is a crucial part of feature rollouts and Flagsmith can help you with its analytics tools. You can track the performance of your feature flags and user segments, monitor how different segments interact with the new features, and make adjustments as needed.

For example, you might decide to increase the rollout percentage or adjust segment definitions based on user feedback.

Some best practices:

• Start small: To test out segmentation, it’s a good idea to start small and create well-defined segments to test new features. This will help you gather valuable feedback and will prevent you from being overwhelmed in case of degraded performance or a rollback scenario.

• Use data: Analytical tools are a great help in gathering data on how different segments interact with your features. You can use this data to refine your targeting and improve the user experience.

• Iterate: You’ll likely make better decisions after several iterations. So remember that you should iterate your segmentation and rollouts based on metrics and user feedback.

Some common pitfalls:

• Overlapping segments: Distinction between segmentations is the key to avoiding conflicts between feature targeting. Always be careful while defining segments for your user groups.

• Ignoring feedback: The greatest mistake a product team can make is to overlook early user feedback. Early feedback is crucial for identifying issues and making informed decisions about a feature rollout.

By following these steps and best practices, you can effectively use this granular segmentation approach, ensuring that your feature rollouts are targeted, relevant, and successful.

Benefits of Granular Segmentation for User Engagement

Improved User Satisfaction

Granular segmentation helps your users out, as it gives them specifically personalized features according to their needs and inclinations. You can build more personalized experiences by aiming certain features at particular users that match their behavior or interest.

For example, a fitness app might launch an update that contains a workout feature for those users who have shown interest in strength building, rather than for all users. This targeted approach ensures that users receive updates related to and suitable to them, which leads to a positive experience, increased satisfaction, and better recognition of your product.

Increased Engagement

When users get features or updates that are targeted toward their specific needs, it’s more likely that they’ll engage with that feature. Granular segmentation helps maximize engagement by providing users with upgrades that are pertinent to their interests and usage patterns.

For example, an e-commerce platform could propose a new recommendation system and try it out on users who recurrently browse specific categories. This relevant targeting will likely increase the probability that those users will respond to those recommendations, leading to increased engagement and potentially higher conversions.

Enhanced Feature Adoption

Targeting specific segments of users with features that address their needs should lead to higher adoption rates. Presenting new features to users who are very likely to benefit from them, you increase the probability of these features being adopted and utilized.

For example, a software company introducing a new improved analytics tool would likely target power users who consistently use analytics features. After those users provide positive feedback and adopt the tool, it can be deployed on other segments. Then the team can be confident that the feature is approved and effective.

Data-Driven Insights

Granular segmentation offers valuable insights into how various user groups engage with new features. Analyzing this data can provide you insights into the behavior and inclinations your users as well as the overall impact of your features.

For example, you might realize that users are responsive to new features in a specific segment compared to other segments. Such information helps you refine your feature strategy, making rational decisions regarding future launches, and enhancing user engagement across different segments.

Optimized Resource Allocation

Centering on targeted segments lets you allocate resources more effectively. instead of investing in a broad, one-size-fits-all approach, you can direct your initiative towards segments that are likely to benefit from and engage with new features. This optimized allocation assures that your resources are utilized efficiently, leading to positive outcomes and a higher return on investment.

By leveraging granular segmentation, you can enhance user engagement, improve feature adoption, and gain valuable insights, all of which contribute to a more successful and user-centric feature rollout strategy.

Conclusion

In this article, we discussed the power of granular user segmentation in driving successful feature rollouts, highlighting how it can improve user satisfaction, engagement, and adoption rates. We also explored how Flagsmith enables this approach, offering tools to manage and target features with precision.

By leveraging these strategies, you can ensure that your product updates are more relevant and impactful. If you're interested in optimizing your feature rollouts, consider exploring Flagsmith’s capabilities to start making data-driven decisions.

In the early stages of a SaaS product, it's easy to get caught up in the excitement of designing elaborate architectures, experimenting with bleeding-edge frameworks, and optimizing every line of code. While these things are important, they can also become significant roadblocks if taken too far.

I've seen projects stall for months as developers (myself) debated the merits of different databases or attempted to master a complex framework before writing a single line of product code. This kind of overengineering can drain resources, delay launches, and ultimately put the entire project at risk.

One of the most valuable lessons I've learned is the power of leveraging familiar technologies. When you and your team know a toolset inside and out, you can build features faster, troubleshoot more efficiently, and deliver a more stable product.

This doesn't mean you should never learn new things. But in the early stages of a product, where speed is crucial, it's often more beneficial to focus on building something that works, rather than something that's technically impressive but takes forever to complete.

As your product matures and gains traction, there will be opportunities to experiment with new technologies and optimize your tech stack. But in the beginning, the most important thing is to get your product in front of users and start gathering feedback.

What Tech Stack Should I Use?

There's no one-size-fits-all answer when it comes to the perfect tech stack. The best choice for you will depend on several factors:

• Your Use Case: What kind of SaaS product are you building? Different types of applications may benefit from different technologies. For example, a real-time collaboration tool might prioritize WebSocket and reactive frameworks, while a data-heavy analytics platform might favor a robust database and powerful server-side processing.
• Your Team's Expertise: Don't underestimate the value of familiarity. If your team is already proficient in a particular language or framework, leverage that expertise. It'll save you valuable time and reduce the risk of running into unexpected issues.
• Scalability and Performance Requirements: Do you anticipate rapid growth? If so, choose a tech stack that can scale with your user base and traffic. Consider cloud-based solutions and technologies that are known for their performance and reliability.

General Recommendations

While there's no magic formula, here are some general recommendations for SaaS tech stacks (for web apps) that have proven successful:

Front-End

• React/NextJS: A popular JavaScript library for building user interfaces. It's known for its flexibility, component-based architecture, and large community.
• Vue.js: Another popular JavaScript framework that's easy to learn and integrate into existing projects.
• Angular: A full-featured framework developed by Google, offering a structured approach to building complex applications.

Back-End

• Node.js: A JavaScript runtime environment that allows you to use JavaScript for server-side development. It's known for its speed, scalability, and large ecosystem of libraries and frameworks.
• Python (with Django or FastAPI): A versatile language that's great for rapid development and data-intensive applications. Django and Flask are popular frameworks that provide structure and simplify common tasks.
• Ruby (with Rails): Known for its convention-over-configuration approach and developer-friendly tools, Rails can help you build web applications quickly and efficiently.

Database

• PostgreSQL: A powerful and reliable open-source relational database that offers strong support for complex queries, data integrity, and scalability.
• MongoDB/DynamoDB: A NoSQL database that's flexible and scalable, making it a good choice for applications with evolving data models or unstructured data.

Additional Considerations

• Authentication: Authentication is one of those systems you don’t want to build, so use third party services like Auth0 to get you started quickly and that would scale as you grow.
• Caching: Consider using a caching layer like Redis to improve performance and reduce database load.
• Queueing: For background tasks and asynchronous processing, message queues like RabbitMQ, Kafka, or Amazon SQS can be valuable.
• Monitoring and Logging: Implement tools like Datadog, Sentry to monitor your application's performance and track errors.

Why this Stack?

• Speed to Market: This stack combines familiar technologies (JavaScript, Python) with modern frameworks (React, Django/Flask, Express/NestJS) that facilitate rapid development.
• Scalability: AWS, Azure, and GCP offer auto-scaling and other features that allow your application to grow with your user base. PostgreSQL and MongoDB are known for their scalability.
• Flexibility: This stack supports both relational and NoSQL databases, giving you flexibility to choose the right data model for your application. The three major cloud providers offer a variety of services to meet your evolving needs.
• Community and Support: All of these technologies have large, active communities and extensive documentation, making it easier to find help and resources when you need them.

Conclusion

Choosing the right tech stack for your SaaS product is a critical decision, but it's important to remember that technology is just one ingredient in the recipe for success. A well-validated idea, a strong team, and a relentless focus on delivering value to customers are all equally important.

Throughout my journey as a developer, I've learned a few key lessons:

• Prioritize Speed to Market: Don't let the pursuit of technological perfection delay your launch. Get your product in front of users as quickly as possible to gather feedback and iterate.
• Embrace Familiarity: Leverage the technologies you know and love to minimize the learning curve and maximize productivity.
• Start Simple, Then Scale: Begin with a minimum viable product (MVP) and the simplest tech stack that meets your needs. You can always evolve and optimize as you grow.
• Don't Be Afraid to Pivot: Be open to changing your tech stack if it no longer serves your needs. The right tools at one stage of your product's lifecycle may not be the right tools later on.
• Focus on the User: Ultimately, your tech stack is just a means to an end. The most important thing is to build a product that solves a real problem for your users and delivers exceptional value.

By prioritizing speed to market, leveraging your team's strengths, and remaining adaptable, you'll be well on your way to building a successful SaaS product. Remember, the best tech stack is the one that empowers you to create something truly meaningful for your customers.

We just posted a course on the freeCodeCamp.org YouTube channel that will guide you through every step of building and deploying a full-stack AI SaaS application.

Elliott Chong created this course. He is known for his in-depth tutorials on AI-powered applications. By the end of this course, you will have a fully functional app that allows users to chat with any PDF using the OpenAI API.

Here are some of the course highlights.

🌐 Building a Full Stack AI SaaS from Scratch:
Dive deep into the world of SaaS development as you construct a cutting-edge AI-powered application from the ground up. Learn how to create a fully functional SaaS using Next.js, OpenAI, TypeScript, and Tailwind.

💰 Monetization with Stripe:
Discover how to monetize your SaaS application by integrating Stripe payment processing seamlessly. Implement a subscription-based revenue models.

🌟 Next.js 13.4 and App Router:
Harness the power of Next.js 13's state-of-the-art App Router to create dynamic and responsive web applications.

🎨 Tailwind CSS and Shadcn for Stunning UI:
Learn to design stunning user interfaces with the elegance of Tailwind CSS and the beauty of Shadcn.

🧠 OpenAI's Language Model API:
Unleash the capabilities of OpenAI's API to empower your application with natural language understanding and generation.

🗄️ Efficient Database Management with ORMs:
Master the art of efficient database interactions using DrizzleORM and gain valuable insights into managing data effectively.

The course is divided into the following sections:

• Intro & Demo
• Set Up NextJS
• Set Up Shadcn
• Set Up ClerkAuth
• Home Page
• DrizzleORM
• File Upload Component
• Set Up AWS S3
• AI RAG Explanation
• React Query Set Up
• Set Up Pinecone DB
• Chat Side Bar
• PDF Viewer
• Chat Component ( Vercel AI SDK )
• Pinecone OpenAI Get Context
• Persist Chat Logs to DB
• Stripe Integration
• Deploy and Outro

You can watch the complete course on the freeCodeCamp.org YouTube channel (4-hour watch).

We just published a course on the freeCodeCamp.org YouTube channel that will teach you how to build your own SaaS app. In this case, a PagerDuty clone.

Ania Kubów developed this course. She creates popular software tutorials on both the freeCodeCamp channel and her own channel.

In this tutorial, Ania will teach you how to build a dashboard to let you know if your app is down. And if your app goes down you will be notified via email and SMS. This is a clone of the popular software as a service app called PagerDuty.

In this tutorial, we will recreate some of the key components of this application using JavaScript for our application logic, Postgres to store our data, and Twilio to power SMS notifications & SMTP.

By the end of this tutorial, you will be able to:

• Create data structures in Postgres to feed into your application.
• Create a UI and feed data into the UI.
• Add functionality to the UI to interact and modify the data.
• And finally hook up Twilio and SMTP to send email notifications and SMS notifications

Here are all the sections in this course:

• Working with pre-made UI Components
• Setting up our Postgres database
• Creating Tables in Postgres
• Feeding in Data to our Dashboard
• Adding new Incidents
• Deleting Incidents
• The Team members page
• Hooking up the Twilio and SMPT API

Watch the full course below or on the freeCodeCamp.org YouTube channel (1-hour watch).

Video Transcript

(autogenerated)

Hey everyone here on the freeCodeCamp channel.In this tutorial, I'm going to be building a tool that every app on startup should have.

I'm going to build a dashboard to let you know if your app is down. And if it does notify you via email and SMS.

So in other words, it clone of the popular software as a service app pager duty.

My name is Ania Kubow. And I'm a course creator here on Free Code Camp, as well as on my own channel.

And I'm going to be your guide to this wonderful tutorial on building this platform here today.

One of the best ways to learn software development is to create a slimmed down version of software you use every day to get a better understanding of how it might work.

This process helps you understand the problem space constraints and techniques required to build a real world use case pager duty is awesome as it helps alert teams to high priority incidents like web outages or security issues using pre configured configuration strategies, and multi channel notifications.

In this tutorial, we will recreate some of the key components of this application using JavaScript for our application logic.

Postgres is store our data, results of other user interface and back end workflows.

And finally Twilio to power SMS notification as well as SMTP.

By the end of this tutorial, you will be able to create data structures and Postgres to feed into your application.

This will include creating an incidence table as well as team members table, we will then feed this data into our UI so we can see it and interact with it.

So as you will see here under the incidents tab, and the team members tab, that we are bringing back all that data.

The Team Members tab will also help us see who is working on what, as well as their shift times so that we can tell who is on call.

And when we will also then be able to see all the incidents that are currently acknowledged and being worked on, as well as filter them down to just the ones assigned to a specific user.

We will add functionality to bring up data if we click on specific rows, and much more, we will also add the ability to add team members from the interface as well as add in new incidents via the interface as well as delete a team member or delete an interface.

So bunch of stuff going on here.

And finally, we will hook up Twilio and SMTP. So that we can send email notifications and SMS notifications to our team members in case the website theoretically goes down.

This video is created thanks to a grant from resource, the local solution for building internal tools and platforms.

So what are we waiting for? Let's do it. Okay, so let's do it.

First off, I'm just going to create a new app.

So I'm just going to go ahead and click on here.

And I'm going to call this pager duty club.

Okay, and click create the app.

So there we go, we've just created our app, essentially, this is essentially our work zone.

And I'm going to start off by just dragging in some UI in order to make it look like a pager duty clone.

So the first thing I'm going to do is actually just drag in some tabs containers, as we're gonna have two tabs here, one to view the incidents, and one to view all our team members.

So let's make that reflect here.

We can also rename this actual UI component.

So I can call it main tabs if I wish.

Okay, great.

And I'm here, I'm just going to change this to say incidents.

And this one to say team members.

So we are literally just creating our tabs container, just like so.

We can of course, also change the colors of this.

So if you just highlight the whole UI component, and then go down here, I can choose the header background color, I can choose the footer background color, or I could just choose the background, I'm going to go ahead with Canvas to make it much the background that we have.

Okay, and if we wanted a little darker, we can also choose our own custom color.

So for example, I could do hex E, E, E, or just three E's for short.

And that will also be applied.

Wonderful.

To get rid of the third view that we are not going to be using simply just go ahead and click on here and delete it from view.

So there we have it, one view and a second view.

We can also personalize the actual selected colors.

So I'm gonna go with green for now as I think it looks better.

Okay.

Wonderful.

Now, under

incidents, what do we want to show? Well, we should probably have some kind of header, right.

So let's go ahead and select a text option, we're going to have a simple text, or we're going to have a text area, or rich text editor, or even editable text, I'm just going to go ahead and select the text option.

And we can even choose if we would like to use HTML elements to kind of decide how big each of the text elements are going to be.

So I can have incidents on all teams as a title, just like so.

And it's styled like an h1 element title.

If you wanted to give a custom styling to this h1 element, that is also possible, okay, all you would have to do is go to scripts and styles and add in some custom CSS for this whole document.

We are not going to be doing that now.

But I just thought it was worth giving you a sneak peek at that.

Next up, what do I want? Well, we can have dividers to kind of separate out everything in here.

So I'm going to in fact, use a divider to separate the title from the table that we are going to input.

Now let's put in a table.

So our table at the moment is not going to mean much.

Okay, it's just going to have some dummy data in there.

So there is some dummy data that's being fed in, we're going to delete all of this as we're going to use some actual data from a Postgres database that we are going to make.

So just leave that blank for now.

In the meantime, I'm also just going to drag in some text to go below here.

And I'm going to use the H five element this time, so a smaller header

to say, your open incidents

and then just drag in some more texts, so that we can actually see those incidents.

For now I'm going to put zero triggered and make this red.

So the text is going to be danger.

And then just copy and paste that.

And this time, this is going to be to show our acknowledged incidents.

And I'm going to change this color to be info.

Okay,

wonderful.

So there's a lot you can do with styling with this text, I'm going to leave it like that for now.

And we're going to choose this number dynamically based off our you guessed it, our database.

So in fact, I'm just going to copy this and paste it because we're going to drag this over to the right and see all our open incidents as well.

So we've got your open incidents, let's also have all open incidents.

And again, we're going to feed that number in dynamically on component text seven, and component text five.

Great.

Now I'm going to add a button, this button was clicked, it's going to help us add a new incident to our database.

So we can actually do that from our UI, which is kind of cool.

And this button, we can style it up.

So I can have an incident if I wish.

And let's make this blue, green just to match the rest of this board.

And I can even choose to make it a little bit bigger.

Next, I'm just going to use a container to contain a bunch of stuff that I want to add next.

So I'm just going to put that in here like so for now.

And this time, in fact, I'm going to get rid of the header.

So we can do that, we can select the whole UI component, and then I can choose to hide the header.

So at the moment, we're just showing the body if you wanted to show footer, then you can do that.

That is totally up to you.

Okay, wonderful.

So we have one container, I'm actually going to have to so I'm just going to drag in another one right below here.

Okay, so that we go.

This one again, I don't want to have a header showing, so I'm just going to hide it now and the first one, we're going to just display who is on call.

So I'm going to just have the title here of encore.

Okay, and I'm just going to make it green.

So I'm going to change the color to be green of the text.

We can also make it bold if we wish.

Okay, so I'm just going to use a opening and a closing tag for that to make that bold.

That name next thing I'm going to drag in is a place to actually display whoever is currently on call.

So for now I'm just going to put x x x as we don't really know who's on call yet.

because, once again, we're going to get that from our database.

So I'm just going to also make sure that it's an h3 element, just like that, just to make sure it's a bit bolder.

And we can even use an avatar.

So I can just drag in a premade component.

That's right, that will show us our avatar.

At the moment.

Again, this is just based off my information, my user detail, I'm the current user of this app.

But we will over write this.

So in fact, just so I don't forget to do this, I'm just going to put x x x for all of these so that we don't forget to add that in dynamically.

Great.

Now, we can put a divider or we can add a footer is totally up to you.

Let's choose to add a footer.

And in the footer, here, I'm going to add some more information, I'm going to drag in a text component, just like so.

And here, I'm going to put in a bolt you are on call for.

And once again, this is going to be fed dynamically, I'm going to essentially create a list of tags.

So we can find these tags in here too.

And I'm just going to put them in below.

Just like sir.

Okay, so that's going to display what we as the person on call on call for.

In here, again, I'm just going to drag in some more tax, this is going to say and called on call.

Now.

Let's go ahead and make this color green.

And here, we're just going to list out all the incidents that we are currently on call for.

Okay, so I'm going to exercise for now as that will be fed dynamically.

And we're also going to show the shift of the current person that is on call.

So it's really obvious.

I'm going to put once again and fold your shift,

and then close this tag.

And then actually display the two shift times as well as some contact information.

So this is going to be from, we're going to put our starting time of the shift, and this is going to be two and we're going to put the end time of the shift of the current person on call.

And here, I'm just going to put some information like contact.

And then I'm going to put info at

Free Code camp.org as well pretending business free code camps pager duty app to make any changes to your shift.

Okay, wonderful.

So that's really it.

Okay, so that's for showing all the incidents.

Of course, we haven't hooked this up to any data quite yet.

Let's work on the team members tab next.

So just like with the team members tab, in fact, what I'm going to do is so super simple, I'm just going to copy this, I'm going to copy the divider, we're going to copy the button.

And I'm also going to copy this container

and click Command C.

And inside here, I'm just going to paste it in.

Okay, so it looks kind of similar.

We're going to change this title to say, team members, okay.

And on the Add incident button, well, I'm going to put add, new team member, of course, as this is dealing with team members.

And in here, well, let's just delete that we don't really want that, I'm just going to show the selected team member from the table that we're going to have, we're not going to have an avatar.

So let's delete that we're not going to have your own code for instead, we're going to have a signed operations.

So we can see the assigned operations that are there for the user.

Okay, so there we go, we have the same operations that will be viewed as a tag list.

And I'm also going to put in the shift dates for the user we are selecting.

OK, so once again, in bold, I'm just going to put shift dates

and close that off.

Okay, and once again, let's just put from

two

and then I'm also going to put the evil of the person that we want to contact.

Okay, so our emails gonna go.

Great.

Now one small is also dragging a table, as this is going to show all our team members from what you guessed, our Postgres database.

So let's go ahead and delete all that data.

That is some fake data that has been passed through

And finally, outside of the incidents and outside of the members, so outside of this whole tab container, I'm going to have another container.

Okay, so I'm going to put in a container.

In fact, let's make a form, as essentially, we are going to be sending something from here, we're gonna be sending an email.

Okay.

So there we go, there is an email form for us.

And I'm just going to put email

composer, as that is what I want to build, let's make the title of this the header, I'm going to change the color of the header.

So if we find the header background, I'm just going to go with highlight as the color of choice.

And let's change the Submit button to I'm going to make a warning.

Okay, and in here I'm going to put to send to, and then whoever we are highlighting from the team members is going to be the person to receive this email.

So that is going to be quite cool.

And another thing we can do is use the rich text editor.

So now we get a whole rich text editor component, this is pretty cool.

Okay, imagine trying to code that out yourself.

And in here, we're going to put Hi, and we're just going to put the selected user from our table.

So that's it.

That's what we have built so far.

Now let's get to linking all of this up.

So for this tutorial, I'm going to use a render.com lynda.com is essentially a way for us to host our database in a non paid way.

Okay, so please go ahead and just go to the dashboard, sign up, go to the dashboard.

And we are going to sign in, I'm going to just choose to sign in with Google.

Okay, so please choose your own way of signing in, it's up to you.

And once he actually need to click on New, and it's a Postgres database that we are going to be create that is hosted on render, I'm going to call this pager duty as that's what I'm creating this database for, I'm happy for the database to be randomly generated, as well as the user name.

And we're just going to select the free tier and click create database.

Okay, so it really was that easy that is creating.

In the meantime, I'm gonna go here and go to resources.

So let's go ahead and create a new resource is going to be a Postgres SQL database, I'm just going to call it pager duty, as that will be easy for us to find the host.

Well, that is this.

So I'm just going to copy this host name, like so.

But then I'm also going to

have to append

dot Oregon

postgres.render.com.

So just make sure to append that keep the port as 5432.

As you see here, the database name is pager duty.

So let's put that in here.

And as authentication, we're going to use the database username, which is this, and the database password.

So here's the password, please go ahead and use your own because this one will not work after this tutorial is.

So there we go.

I'm going to click connect using SSL.

And let's just test this works.

And connection is a success.

This is because we left the address, IP address as everywhere, okay.

But if you wanted to, you know, keep it kind of private, you might consider adding these IP addresses.

So great.

Let's create a resource.

Let's go back to the resources.

And now I'm just going to shut that down and refresh this.

So it loads the latest resources.

And I'm going to choose pager duty as my resource name, that's just the one I made.

Okay, so I'm actually going to use this UI in order to add the actual tables that I'm going to use for this project.

Okay, so I'm going to just go ahead and create my first table.

So I'm going to use the Create Table command.

And I'm going to create a table of incidents.

Okay, so get up your parenthesis and let's define what's going to go on our table.

Well, I'm going to put an ID, which is going to take an integer value, I'm going to put an urgency level which is just going to take our chart 30.

So 30 characters, essentially, I'm going to have triggered Is this a triggered event? Well, it's yes or no.

So I'm gonna have a Boolean for this.

Next, I'm also gonna have acknowledged, this will also be a Boolean,

as well as resolved, which is also going to be a Boolean.

Next we're going to have a description of the actual incident itself.

So that's going to take

bar char.

And I'm going to actually limit that to 30.

Okay, we don't want them to be too long, and then assigned to, and this is going to take an integer.

In fact, it's going to take the ID of a an employee.

And I'm also going to have a created

date, which is gonna take a date.

So that's what my table looks like, don't forget to finish it off with some semi colons.

Let's check if this works, I'm going to click Save and Run.

And great, that seems to have worked, we haven't got any errors.

And we're gonna call this playground for now, as I'm essentially using this as a little mini playground to add our tables.

Okay, so that was one thing that we have done, you can keep this in here, if you wish.

In fact, I'm just going to comment that out.

Because I'm going to create a new table to create

table team, this is going to take our team.

So what's our team going to be made up of? Well, each team member is going to have an ID, which I'm going to say has to be an integer, they're going to have a first name, which I'm going to take as virtuoso characters, let's just do 30.

Again, a last name, which I'm going to be super strict about this too.

Of course, you don't have to have 30, I'm just choosing to for now.

And an email, var char binders put 225 wide dots, okay, you can have higher character numbers, if you wish.

Next, I'm going to have a phone number of your team mate, which is going to be an integer value, and Avatar, which is actually going to be a URL to an image on the internet.

And then we're going to have on call to check if they're on court or not.

And this is going to be a boolean value, as well as a shift,

start.

And that's going to be a date,

a shift and value, which is also going to be a date, and incidents that they are working on, which is going to be text, but it's also going to be an array of texts.

So that's how I would write that.

Great.

And just finish off some semicolons.

And hit save and run.

So there we go, we have just added our table for team members.

So I'm just going to comment that out.

I'm going to go ahead and just add two incidents just to start off with just so we have stuff to play around with.

So I'm going to insert into the table called incidents.

And we're going to insert an ID and urgency value a triggered value, an AK, knowledge value, resolved value or description assigned to

making sure to spell it exactly the same as we did up here.

created date.

And that should be it.

So those are the values we want to insert into let's actually get the values.

So the value for the ID, I'm going to put incident ID number one, we're going to put urgency as the string of high as well as the triggered is going to be true.

Technology is going to be true and resolved is going to be false.

So we've put in Boolean values for those.

And now I'm just going to put in a description of this incident, it's going to be DevOps escalation.

So just like that, it's going to be assigned to the employee with ID 201.

And then we're just going to put in a date that this was created at, I'm going to put a date in the past, okay, because, you know, we don't want to put everything as today's date.

So there we go.

Okay, and don't forget to finish the off with a semi colon.

Okay, so there is our semicolon, and just hit save and run.

Great.

And that has run successfully.

So that is one incidence, let's just add a another one.

This one is going to have the value of two.

Let's put the

urgency as low.

Let's add true, maybe false false, this time for triggered, acknowledged and resolved.

This one can be called Security ops.

S escalation making sure to spell security correctly.

It's going to be assigned to use a 201 as well.

And let's put this as maybe one day

earlier.

I'm click Save and Run.

Great.

And I'm just going to comment that out.

I am now just going to insert into team so I'm only going to insert one person into here i

Pick, that will be fine, we need to get the ID, we also get the first name of the person we are inserting, and the last name making sure this will exactly the same as we have in this table.

Next up is email.

Next up is the phone number.

Next up is the Avatar.

And I'm going to have on call.

It's up shift

starts

shift and, and the incidence attached to them.

Once again, just making sure that everything is spelled correctly, because next we're going to put in the values.

And the value of this, well, this is going to be team number 201, the name is going to be Ania.

And their last name is going to be Kubo.

Now my email address, I'm just going to put as the string of Ania at Free Code camp.org.

The phone number, I'm just going to put a fake phone number for now.

And as my avatar Well, I'm just going to use my avatar from Free Code Camp.

So please make sure to take an image that you know is unlikely to be taken offline, or alternatively store them yourself on imager.com.

Or you can put them on an external database such as AWS, for example.

So I'm just going to copy this image address.

And I'm just going to paste it in like so.

Now after the avatar, I'm just going to specify if this person is on call, I'm going to put true.

And then I'm going to also

put a made up start shift time, a made up and shift time as a string,

and then an array.

So we can literally just put the word array like so.

And then I'm going to put in dev ops, s collation.

And security ops, a skull escalation as the incidents assigned to this user.

Okay, don't forget to end it with some semicolons, hit save and run it say integer out of range, that's fine, I'll just change the format of the folder.

And now I'm going to add in that Twilio phone number making sure to add 001 at the front and hit Run and safe.

Now it does say that integer out of range, which is kind of strange, I don't think this should be out of range.

But that is fine, we might have to make this a string instead.

So let's go ahead and make that a string, I'm actually going to just comment this out, we're going to drop the table DROP TABLE team.

So essentially, we're going to delete it, because we have to change the data type of the phone number.

So make sure to drop that.

And now I can create a table again.

So this is good for anyone who perhaps made an error in the first place.

And I'm just going to change this to var char as well.

So that will not take a string.

So save that and run it to create this table again, with the number of being an email.

And now we can insert into Tim, after you have commented this out.

So save and run.

And great.

We have now added our first team member, so I'm just going to comment this out for now.

Okay, so that was our playground.

And now I'm going to get some data that we can feed in into our first table of all the incidents.

So let's create a new resource.

And let's make sure that the result is pager duty.

I'm just going to do select all from the table incidents.

And click Save and Run.

Let's see what that looks like.

And indeed, we get two incidents back.

I'm going to rename this get incidents as that is essentially what this query does.

And now in here, instead of adding data manually, I can get incidents and get the data of those incidents so that it feeds in there and it's automatically mapped out to these lovely table rows.

What is cool is if you want to see the whole data object that comes back, you can all you have to do is go to state and get the incidents and there's the data and you will see all that information as

The arrays that we can use.

Okay, so that's just in this tab on the left here, I'm just going to minimize that left panel now.

So that's what I have done.

Let's carry on working on this.

So another cool thing we can do is actually adjust which kind of columns do you want to see or edit or anything like that.

So for example, I can choose to hide the description if I want.

So I'm just going to select the whole table.

And I'm going to choose to hide the description by pressing on this little irate here, I'm also going to hide the assigned to, I'm going to keep the created date.

And I can even if I want, add a new column, add a custom column.

And this column is going to help me delete incidents if I want.

So at the moment, I'm not really going to put anything in here apart from just decide that it's going to be a button.

Okay, that is my button.

And the value of this is just going to say, delete.

So there we go, we can of course, make the columns smaller if we wish, and just in general, play around with this a little bit better.

So I'm happy with this table.

Let's now change the value of this hard coded zero.

And I can do so easily, I can literally get the incidence data.

And I can look inside to see how many of the objects triggered are true, right.

So for this, I'm going to use the filter method.

And I'm going to look through each item, okay, by essentially filtering through each one, and used AI as the representation of each item that we are filtering.

And if i equals true, I'm going to get the length of that array.

So as you will see here, two incidents are triggered.

And if we look here, indeed, two incidents are triggered.

So if we do the same for acknowledge, we should get one acknowledged incident.

So let's try again, we'll use the two curly braces as that is how we do things in retool in order to get values from the queries.

So the query we wrote is called Get incidents, right.

So I'm essentially getting the name of whatever we called this query and getting the data from it.

And I am going to this time filter by the acknowledged, so I'm going to get acknowledged and use the filter method on it to essentially filter and if I or each item in that array equals true, I'm going to get the whole arrays length.

And indeed, we get a one.

So once again, curly braces, in order to access data from the queries, the query I wanted to access is the get incidents query, you can see all the information that comes back here.

And again, if you really want to see the whole object, we can look in here.

So I've got incidents I've got into the data object, then I've gone into the acknowledged array, and I filtered out anything that is equal to true and got the length of that array.

Got it? Cool.

Okay, so to do your open incidents, we're going to have to do something else, because we're going to actually have to get the user.

Okay, so perhaps let's do that next.

Now, who was the user? Well, I think the user should be whoever's on call, right.

So let's go ahead and create a new resource query, I'm going to call this get user.

And I'm going to select all from team this time.

So the table of team were on call equals true, I'm going to save and run this.

So there we go, it comes back with one user and at all points, we really should only have one person on call, right.

So that is a kind of rule that should be done in the backend, this isn't a front end thing.

So we can just assume that this will come back with one user at all times.

So that is going to be a user.

And I'm going to filter incidents by the user.

So let's try another resource.

I'm going to write filter incidents.

And I'm going to select all, from incidents.

were assigned

to equals and then I'm just gonna get the user data.

So this is our get user query.

We're going to get the ID but only going to get the first ID from the array because we are assuming there is only one so that should be fine.

And don't forget your semicolons at the end, so

I'm just going to save and run that.

And making sure to spell incidents there correctly.

Just run that again.

Okay, so two items come back.

This is because indeed, two items are assigned to me and your Kuba because my user ID is 201.

Great.

Once we get to adding more incidents in here, you will see how that changes.

So now that means I can use my filter incidents query to dynamically update these.

So once again, use our curly braces, filter incidence is the query I want to use, I want to get the data from it.

And I want to get the triggered.

array.

And I want to filter it based on if I have the item in here in this array equals true, and I want to get its length.

Okay, so to will be triggered, that is correct, because I'm just going on my open incidents.

And other moment, I'm the only user in here.

So once again, you guessed it, we're gonna get the curly braces, we're gonna get the filtered incidents.

So let's get the filter incidents data.

And this time, we're going to get the acknowledged array and filter it by looping over i and if i equals true, we're going to get to the length of this array at the end.

Wonderful.

So this is all looking good.

We can now actually also fill out this because we aren't technically getting the user.

So we can use this query, let's run it again and see what it looks like to find out who's on call, right? So I can use my curly braces, to go into the get user query and get the data and get the first name that comes back to us.

Okay, so I'm going to get the first name.

And I could also put the second name, I've literally just put a space there, this will work, I'm going to get user data.

Last Name, great.

And same for the avatar, well, I'm going to get user data,

Avatar at this time, and just go into the first item of that array.

Same for the email.

So on the label here, I'm just going to get into get user data to the email

and get the first item from the array.

In fact, maybe we should have that on the actual caption of the label.

And here, we will just have the first name again.

So I'm just going to take all of this

and whack it onto the label here.

We can also essentially map out what the tags are.

And here we're going to get the incidents, right, so let's get rid of that curly braces, get user data incidents.

And we're gonna have to go into the first item, that array.

And there we go.

So these incidents have now been mapped out onto here.

Great.

Let's also do the same for here.

So I'm just going to show all the incidents, I'm going to get the user data incidents.

And actually, if I treat this as an element, we can actually just put the array in here like so.

Okay, so that's something I have done.

Now, from here, I'm just gonna get into the user again data and get the

shift start.

And once again, on here, I'm going to get user data, this time shift, and great.

So we've populated all of that base of the get user query.

How cool is that? Next up was work on adding an incident.

So for this, I'm actually going to create a modal that's going to pop up.

So in fact, let's go ahead and just put that up here.

And I'm just going to delete this button.

So delete it, and I'm going to change the text of this to be add incident.

Let's also change it to be green.

So I'm just going to minimize that for now.

As well as the state.

The accent background is going to be green.

We're just going to make it a little bit bigger.

Okay, so that is our modal.

And here I'm just going to put in some tags.

So I'm going to drag in some texts, and this is going to say add incident.

I'm going to make this an h2 element, add

incident

Just like so

let's also put a divider, I'm going to put that in right down here.

And then I'm going to create a number input.

So one specifically to put in numbers.

So just like that with a label in incident ID.

Great.

Next, I'm going to create a drop down.

So I'm going to have this select drop down, just like so.

And I'm going to put the value of the label as urgency.

And I'm going to hard code my options, option one is going to be high, option two is going to be medium.

And option three is of course going to be low.

So those are my options.

And if you leave the label as empty, it will just take the value as the default.

And I'm happy with that.

Next, I'm just going to create some

switches.

So this is because I'm going to be dealing with Boolean values, so I'm fine with this, I'm going to have one for triggered.

Let's also have one for acknowledged.

And finally, let's have one for resolved.

Okay, so those are my three options right? There.

You can of course, start them up as much as you want.

Next, we're going to have a description input.

So for this, I think we should just have some text.

So I'm going to put in a text input.

This is why I kept the description short, Max 30 characters, because you know, that's not a lot to work with.

And we can also cap this as well.

So we can cap the value.

You can have a max length of 30, just like so.

And let's go ahead and put description

here.

And finally, let's have one more select drop down.

So select.

And here, we're going to select who this is assigned to.

So I'm going to put assigned to.

And instead of having options, I'm going to map out the options, this time, the data source for this, well, we're going to have to get all the team members, right, so let's go ahead and write a new query, I'm going to call this get team and we're gonna get all the team members.

And the query for this is select all from Team and run it.

So that's going to be the data source, get team.

And that's going to auto populate for you.

And great, this is fantastic is exactly what I want.

Okay, so now we can actually choose which team member to select in such a nice way.

Okay, and whichever one we select, it's actually going to pick out the ID of that item.

So if I select me, the value of this, when it's selected will be 201.

So readable, and then practical.

Great.

And finally, I'm just going to put in a button,

that's going to submit this modal.

So I'm just going to put Summit, and we can actually make the height of this Moodle dynamic based on what's inside.

So I can do hug content, and then that will happen.

Okay, wonderful.

Now let's write a query for adding an incident.

So add incident, just like so making sure the resource is pager duty.

And once again, we're essentially going to use this piece of code.

So I'm just going to copy all of that, because that is the code that we will need in order to add a new incident, of course when it's uncommented out.

So that's what we are going to insert into the table incidents.

However, this time the values will not be hard coded.

They will in fact be taken from here.

So I'm going to use my curly braces to access this component which is called number input one number input one and get its value.

If you hover over that you will see that zero well if I change this that will change and you will see the value is now two

Okay, so as literally getting the value of that input, this second one is the urgency, right.

And this component is called select one.

So I'm going to gret select one and get its value once more.

So if I choose high, that will now be high.

Wonderful.

So hopefully that's kind of making sense.

Next, we're going to go on these switches.

So that is going to be switch one, two, and three.

So once again, I'm just gonna use my curly braces to get switch ones value, switch, two's value, as long as these are of course in the correct order.

And then switch threes value switch, three, value.

And finally, I'm just going to minimize this, we need to get the description which is text input one, and the Select to value.

So description is going to go here.

And that is text input value one, I believe, yes, text input one and select two.

So select to value, and we're just going to get today's date.

So I'm going to use the new date object from JavaScript to do that, once again, make sure it's in curly braces, and just call it.

So that's what I've done, I'm essentially getting the values of all these inputs, let's have a go at filling this out.

So let's go Incident Number three, urgency, high triggered, acknowledge, not resolved description, well, I can go ahead and put anything I want, let's put

deployment.

And assigned to what I'm the only one here right now.

So great.

And now this button, well, we need to trigger the Add incident query we just wrote.

So I'm going to add an event listener control query that's been generated for me at incidents because I'm currently on that query.

And we're going to trigger that.

Okay, that looks great to me.

So now, before I submit this, I'm going to run this query with all these values filled out, you will see the values that we are essentially going to put, they've all been now filled out.

And if this works, well on success actually want to do a few things, right, I want to get all the incidents again.

So the freshest incidents, and I also want the modal to close.

So I'm going to control a component to this time.

And that component is the modal.

So let's go ahead and find it.

And I want it to close, we can also add some other fun things like confetti if we want.

So confetti, let's go ahead and do that.

And save.

So I haven't run this because I want to trigger it by pressing this button.

So I'm going to click on here,

we have got an error, let's debug.

It would seem I just put a extra

string, I didn't delete those strings properly.

So now let's save.

Let's try it again.

And hit submit.

And great that has worked.

And tada, we have gotten the fresh incidents again.

And that has updated our table.

So this is looking great.

And you will see that this has been updated to

oh, this has not been updated.

That's because we of course also need to run the filter incidents method as well.

So on success of adding an incident, let's add the gets filtered incidents also.

Okay, so there we go.

Now I've just run that again.

So we would have added the same stuff again, because as you will see, that information is still there.

So now let's work on deleting that third one, okay, because we don't want it but at least we know this is working.

And this is working and everything is updating.

So now let's work on it deleting an incident.

So this one I'm going to call delete incident.

The resource is going to be pager duty, and all I'm going to do is delete from incidents where ID equals and then this is table one selected row.

Data it so this for the either it is going to cause a problem.

This is because you know, if we essentially delete, this one is going to look at the ID and it's going to delete both of these.

So just keep in mind that whenever you add an incident that Id needs to be unique.

So save that and onsuccess of this well once again, I'm going to essentially get all the incidents

and run

The filter incidents query once more.

So let's save that.

And now let's hook up this button to that.

So let's find that custom button that we made an on click, we're going to run a query, and that query is delete incident.

Okay, so that's what we want to happen.

Now let's try it out.

I'm going to click Delete incident.

And that should delete and it's deleted all of these incidents, and it's gotten all the incidents again, so we can view them in the table.

And it's updated these based on the filter incident query and the get incident query.

Wonderful.

So I'm really happy with this.

Let's carry on.

Okay, now it's time to move on to the team members page.

So in here, let's go ahead and use the get team query in order to populate this table.

So once again, I will use my curly braces, get the get team query and the data from it.

And that should automatically update my table right here.

Again, we can choose which columns to hide, so I'm going to hide the avatar column, this time, I'm going to hide the phone number, I'm also going to hide the start shift and the end shift as well as the incidence, okay, and I'm going to add a custom column once again, to be able to delete that user.

So this is going to be a button.

So let's go ahead and do that.

So there we go, there is a button that says, delete after we update the value.

So great.

Before we go deleting anything, let's populate this container with this selected user, as well as add functionality to add a new team member.

So to do this, I'm actually going to rename this component, as I mentioned, this is something you can do.

So I'm just going to call it team table.

Okay.

And that just makes it more reasonable for when I use this table.

So the team table, so I can literally use my curly braces, to access the team table component

and get the selected row data.

And I could just grab the first name, if I wish of that selected row.

And of course, I could do so for the last name too.

So once again, that's going to Bacardi braces.

And I'm just going to use 10 tables selected row data.

Last Name, this time.

And Wonderful.

Great, we can also use the avatar that I have hidden from the table, but it still does exist.

So if I want to just go ahead and grab an image,

just like so.

And now I can go into the team table on small selection of data and get the avatar as that exists.

On here, even though it's a deleted column.

Once again, if you want to have a look at the objects for this, just have a look in here look at get team data.

And we're getting the selected row data, right avatar.

And that is the URL that I am getting.

Great.

And now let's populate these other components.

So here once again, I would delete all that would use the team table selected row data to get the array of incidents that will be mapped out onto these tags.

And you know what to do this should be easy.

Now once again, let's go into the team table selected row data and get the shift start time.

And then also get this shift and time.

So team table, select data,

shift and is what I want.

And here I'm just going to display the email address.

So once again, Team table selected or data dot email.

Wonderful.

And that was it very painless.

Now let's get to adding a new team member.

So for this, I'm actually going to use the modal components.

I'm just going to put that in here for now and it's delete this button.

So I'm just going to delete that and move this over.

So move over the modal button

just to here.

It's going to make it a little bit bigger.

And of course we can style it up.

I'm just going to make everything green.

And then it's changed the font of this to be add new team member.

Great.

So now let's work on the modal

So for this, I'm just going to drag in some text, let's make this an h3 element.

And it's gonna say add a new team member.

Just like that.

And I'm just going to drag it out, I'm also going to have another divisor just like we did previously.

So I can put that divide it in right here.

And then let's add some inputs.

So I'm going to put a number input.

And this is going to say, Team Member ID.

So let's change the text of the label to say, Team Member ID.

Let's also just have a text input, this is going to be for the first name.

And we're gonna also have one for the last name, too.

So let's change this to say, first name.

And I'm literally going to copy and paste.

So the second one shows up.

So I can change this to last name, we're also going to have email.

So there is a special email input we can use.

So there we go, I'm just going to drag that in like so and put it here.

Maybe let's put some two dots there, just so we can make it look the same.

And then we're going to have a phone number.

Well, this is actually a text input as we know, because we changed that to be a text input.

So I'm just going to put phone number like

that.

And it's also an avatar image.

Well, this is just going to be a URL to something on the internet, as we mentioned, for now, of course, you don't have to have it like that, you can link this up to an AWS database if you wish in order to store images.

Next, we need to have a checkbox to allow us to check if someone's on call or not.

Okay, so let's go ahead and put on call here, and then someone can choose to select that or not select that, that'll be up to them.

We also have a date picker.

So I'm going to go ahead and just put in

this date picker right here.

And by default, that will show you today's date, which you can then change.

And I'm going to go ahead and change this label to start dates.

And let's make an end date, one, two, so end date end date of each shift.

And finally, we're also going to have a select by a multiple select, okay, because we can pick multiple

operations assigned to one user.

So I'm just going to change this to operations.

And let's Harker the options, the first one is going to be email ops, escalation,

just like that.

The second one is going to be security ops, escalation.

And the third one is going to be DevOps escalation.

So I'm just going to put dev ops, escalation just like that.

Okay, so now people can select multiple ones, which is quite cool.

And then finally, let's have a submit button.

So I'm just gonna get rid of that and find a button so that people can submit these answers.

So there we go.

And it's changes to say, submit.

So wonderful, I think that is looking good.

Now let's get to writing a query for this.

So this is going to be add team member.

So let's change this say add team member, just make sure that's the correct resource.

And then we are also going to insert into so this is where our playground comes in handy, we're going to insert into team, it's going to grab all of that

team member, just paste it in uncomment that out and just change the values.

So the value of this will be whatever the number input two is.

So let's grab the number input to value.

This will be text input two values, so just get rid of that input, text input two value, and then we have text input three value.

So text input three value

will also have email one, so get rid of that string, input email, one value.

We also then have the phone number, which is text input four.

So let's go ahead and put text input for value.

Then we have the avatar, right, which will be text input five value.

So let's get rid of that text input five value.

And then we have a checkbox.

So the checkbox is checkbox one and then we update one do

To add multi select one, so that's really easy to remember, check box value one, this will be date one.

So date, one value, this will be date to value.

And this will be the multi select options or multi, select one value.

Great.

So now let's save this, I'm actually going to also add some things to do on success because on success, we want to, essentially we get the team, right, so that will happen onsuccess.

And then let's also have some confetti, because why not, let's also close the modal.

So we're going to this time control a component and find the second modal that we made.

So just scroll down for modal two, and then we want to close it.

Okay.

So that's what we want to do on success.

So now I'm going to save that and hook up the Submit button to run that query.

So let's just add an event handler, control query add team member.

So wonderful, let's try it out.

I'm going to put employee to to I'm going to put Beau Carnes and as an email, I'm just gonna go well, at Free Code camp.org.

And as a phone number, I'm just going to make this one up.

Okay, just like that.

And as an avatar image, I'm just going to get one off the internet Akbar.

Okay, so I'm going to copy the image address.

And just paste that in, he's not going to be on call.

And let's put his start date as the 11th.

And the end date as the 14th.

And the operations he's going to be assigned to?

Well, let's have a look.

I think there's just an email ops, and security DevOps as well.

So now let's hit submit.

And great bow has been added.

This is looking wonderful.

And finally, let's add a way to actually delete a team member.

So I'm going to actually do is write a new query.

So let's add a new query resource query, this is going to be delete team number.

Make sure the resource is correct.

And we're going to delete from

team

where the ID equals the team table selected row data ID, right, because we're here, if we're selecting this one, and we want to delete it, we just want to make sure that it's the correct ID.

And that's how we're going to delete that team member.

So on success, we're, of course going to have to rerun the query to get all team members.

So get team and save.

And now we just need to hook up this button.

So let's find that button.

And on click, we want to run a query.

And that query is to delete a team member.

Okay, so there we go.

And Shall we try it out?

Let's do it.

I'm going to delete this team member.

And wonderful, so that we have it.

And I'm just going to Riad him.

Luckily, all of this is still here, as I have not cleared that.

I've done that on purpose, just so it's easy for us for this tutorial, I'm just going to hit submit.

So there's both again.

Now for the email composer, well, it'll be quite nice to have whoever I'm highlighting, have their first name show up.

So that's what I'm going to do.

I'm going to you once again, use the team table, select your data to get the first name of that person.

Okay, so there we go.

It says Hi, Bo.

So this is the default value of our whole rich text editor and put a comma there too.

And here as well, we can show who was sending this to.

So I can use team table selected or data came out this time.

So great.

At the moment, it's showing Bo, the device selects myself, of course, this updates, but this updates to and then I can write an email and send it but of course for that we need to hook this up.

Well, I'm also going to do though, is whenever we send an email, I'm going to also send a text notification.

So that's two resources we need to add.

Let's go ahead and do it.

So I'm going to go to Resources.

And let's just hook up our Twilio that

We signed up to before.

So please go ahead and find Twilio on here.

That is Twilio.

And I'm going to do

and is

Twilio.

Let's get the s ID account.

So here is my account s ID.

Let's get the auth token.

So here is my auth token, I will be deleting this.

So please don't think that it will still work.

If you use it.

I'm just going to select this as it's not allowing me to update the IP addresses.

And let's test the connection.

So that connection is successful.

And let's create a resource.

Wonderful.

So that is now done, I'm going to save these changes.

And let's go back to resources.

And this time, I'm going to create another resource.

This time it's going to be for emailing, I'm just going to scroll down to a previous one that I've made and reconfigure it.

So here are the settings that you need.

However, you do need to have a Google workspace, which is a paid workspace for this to work now.

So my Google workspace credentials are Ania at code with ania.com.

And then I'm just going to put in my password for that email.

Okay, so that's what you need to do, let's test the connection.

And then we're just going to have to allow less secure apps.

So just go to your admin console.

And I'm just going to search for a way to control access to less secure apps.

Okay, so that's here, we go to settings.

And then we go to access and data control and less secure apps.

And I'm going to allow users to manage the less secure apps.

Great.

So that's for all users in my company.

And that connection is a success.

So there we go, we have done it.

Great.

Now let's go back to our app is going to get rid of that.

So now let's hook this up, I'm just going to create a new query.

So let's create a new query resource query, this is going to be to send email.

And this time the resource Well, it's going to be Gmail.

And the from email

is just going to be from Ania at

code with

ania.com.

And the to email is essentially going to be whatever we are selecting right, so the selected row.

So let's go into the team table, select a row data email,

where you can have a BBC or a CC, I'm not going to.

And this is just going to say email from pager duty clone.

And the body.

Well, it's just going to be the body of our rich text editor.

So we're going to go into rich text editor one and get the value.

Okay, great.

And onsuccess.

Let's also just have some confetti, and save that.

And now let's hook it up to the Form button.

So event handler on click, we're going to control the query sent email, because that is the query that we are on now.

So it's picked that up.

Another thing I want to do is actually just sent a text message that we got an email.

So there's gonna be another resource query send text.

And this time, this is going to be the resource Twilio that we just made.

So and use Twilio.

Okay, so that's been pre configured for me.

And this is the operation we need to do.

It's a post request, this is the endpoint and it's populated my account Sid, that is good, too.

Well, who we're going to be sending this to.

I'm going to put in my own phone number in a bit to test this out.

But of course, usually you would go into the team table selected row data and get the phone number right.

So just like that, so let's go ahead and select someone.

So I am selected so that should be bringing up my phone number.

The body I'm just going to put you have an email notification from pager duty clan, and from well from is going to be my Twilio phone number which is actually in fact this you can get it from Twilio as well.

If you don't have a from here, please go ahead and add a parameter by clicking here.

Okay, great.

So that's what we want to do and let's just add some confetti for when this saves

And I'm just going to attach that to this bottom two.

So send a text trigger.

Okay, so both those things will happen.

Now,

because of course, this number doesn't really exist, I am going to put in my phone number.

So please look away.

And let's say this untested out.

And great.

That has worked, I should have received a text.

So let's check it out.

Well, first off, I'm just going to run this and see if that has worked.

And let's see bug.

Okay, just to make sure that you have your email the same one as you are using in the app.

And that should work.

Let's check the Gmail account.

So I'm just going to sign in and check out if I got an email.

And I did.

Okay, here's my email.

Of course, it does come as HTML.

So we're probably gonna have to format that a little bit better.

But at least it's sending something.

So there we have it.

We have completed our pager duty app.

Here is in all its glory.

It works.

The Twilio API works.

The SMTP API works.

We are using a Postgres database, we can add incidents, team members, delete team members, delete incidents.

This is looking glorious.

I hope this tutorial was useful.

And I hope you had fun while learning and I'll see you soon

Here is a full breakdown of what he will cover in this 40 minute talk:

• The reason for this talk
• Why Websockets?
• Websockets minimal API example
• Rest Web Services
• Multiple Listeners
• Full Duplex
• Websockets time-line
• TypeScript
• Vendor Tools
• Auction IDL Definition

This article was written by Ania Kubow in support of the conference talk made by Steven Lemmo.

Code with Ania Kubów

Hello everyone. This channel is run by Ania Kubow. In this channel, I will be teaching you JavaScript,React, HTML, CSS, React-native, Node.js and so much more! A little bit about me:My background is in the financial markets, where I worked as a derivates broker our of University. After starting m…

YouTube

In this article I will share the story of how I became CTO of a software as a service (SaaS) company. It all started about 3 years ago when I was going to hackathons for fun.

At the end of the article you can find some tips and advice I would give to aspiring entrepreneurs as well as some reading recommendations.

It was – and still – is a wild ride!

Our company team (we now have 8 more employees!)

Although I have a good knowledge of entrepreneurship, don't just take my advice at face value. Learn from books, from other entrepreneurs, and from your environment in order to triangulate how best to act in a given situation.

My First Hackathon – Which I Lost

It might sound off, but I had no interest whatsoever in entrepreneurship or business 3 years ago. I was more of a researcher in spirit than an entrepreneur.

From studying memory at the molecular level, to helping schizophrenic patients learn better, or predicting consciousness recovery in patients with traumatic brain injuries, my mind was deeply focused on the frontiers of science.

However, I had a deep passion for programming and for finding ways of building tools that didn't exist before.

Like the time I built a brain computer interface that was compatible with a Transcranial Direct Current Stimulation electroencephalographic headset (that is, it stimulates the brain by giving shocks and lets you control a kind of ping pong game). I just love to build stuff.

Cutting edge graphic from my brain computer interface

So three years ago, my brother wanted to find a new job as a software developer. We figured out that we could attend hackathons to help him get noticed by recruiters.

It was my first hackathon so I was pretty excited to spend two days building something. Our team was composed of myself, my brother, his friend, and one more member (who didn't do a lot, but was still there).

It was two days of heavy coding, and at the end we came up with a pretty cool algorithm to pattern match people with jobs given some characteristics.

On top of that, I met nice people that, like me, love to build stuff. We ended up among the finalists and came in fourth during the final presentation.

Here I am trying to figure out why the clustering is not working

What I learned From My First Hackathon

It was a bit of a bummer not to win, but I realized something important then: except for the participants, no one really cared what I coded during these two days.

It was mostly the presentation of what we wanted to build that mattered. We should have spent a bit more time making a very compelling PowerPoint instead of focusing on the development of an algorithm!

It was a fun learning experience, but my brother didn't get a job out of it – so we were back at square 1.

My Second Hackathon – in Which We Won a Special Prize

I was ready to take a small break from hackathons for a while. However, my brother decided to sign us up anyway. So his friend and I to go to another hackathon right after the first one. I would have refused as I had other stuff to do, but he had already paid the sign up fees.

This hackathon was a bit bigger than the previous one and there were still a bunch of recruiters there. We figure that this could be our second shot at getting him a job.

The theme of this hackathon was open data and environment. So we were in a good position to make something cool with my background in machine learning.

A lot more people where present at HackQC which was nice!

Knowing that the presentation was everything, we decided to be a bit more strategic with this hackathon. We combed all the different prizes we could win and selected the one with seemingly the least competition. The project would deal with the prediction of combined sewage overflow.

We then split up our team of four (another friend of my brother's joined in) so that half of us were working on the coding and the other half on the presentation.

The name of our team was “Égout Quebec” which translates to Sewage Quebec (branding wasn’t our strength). Here is the excerpt from our competition log on DevPost in French:

ÉGOUT QUEBEC permet de prédire le débordement des égouts et d’en avertir les amateurs d’activités aquatiques. Ainsi les personnes désirant aller faire des activités aquatiques pourrons éviter les zones polluées par les déversements d’eau usée. De plus, des conseils seront dispensés aux gens des différents quartier, de façon à réduire les risques de débordement.

ÉGOUT QUEBEC utilise une technologie basée sur une intelligence artificielle. Celle-ci peut déterminer lorsque les égouts déborderont. Ses analyses et calculs sont basés sur des données disponibles sur le site de donnée Québec. Finalement, les différentes villes auront avantage à utiliser ÉGOUT QUEBEC.

Grâce aux prédictions et aux analyses de la plateforme, il sera possible de concentrer les ressources de la ville aux endroits les plus problématique.

All this basically translates to “we found a way to solve the problem using a random forest + a bunch of data”.

We actually ended up winning a $1000 prize, which was huge at that time! We even got a nice glass trophy in the shape of a water droplet. It was less challenging than the previous hackathon because we had a better plan for what we needed to do.

Here we are at the podium (still technically fourth place though).

What I learned From My Second Hackathon

This hackathon made me realize that presentation was indeed important. But I also discovered that focusing on problems that people don't find interesting is a good way of increasing your chance of coming out on top!

Winning felt good and I was ready to take my share of the $1000 prize and call it a day...

My Third (and Last) Hackathon – Which We Kinda Lost Again

However, the $1000 prize came with an automatic fast-track to the semi-final of yet another hackathon! This one had higher stakes with a $25,000 prize.

We met up at a coffee shop to figure out if we wanted to split up the money or to use it in order to take our project to the next level.

After looking at the other participants' projects and the rules of the competition, we decided that we actually had a good shot to at least get to the finals. This would unlock some more funding which we could use at will and would give us a nice trip in the summer to a lake in Ontario.

This hackathon wasn't like the others in the sense that it ran for the whole year. It was more of a take-home hackathon, which was great for me since I didn't have to do that insane two-day time crunch routine over a weekend.

We changed our name to EGC Labs and managed to get a website together to advertise our sewer overflow prediction solution (which was working surprisingly well). We then went to the semi-finals competition in Ontario, and to our amazement we moved on to the final!

Here we are as finalists! I didn't go all the way to Ontario for the semi-finals, though.

This was great! We had a very good shot at winning more than a small stipend, and maybe starting a business out of this thing. To help us bootstrap ourselves, Aquahacking generously gave us $2000 and École de technologie supérieure (ÉTS) gave us $1000 for travel expanses.

However, we still didn't have any customers for our solution, which was a bit problematic.

We tried to contact a bunch of cities in Quebec in order to see if they would be interested in our sewage overflow application. We had some pretty advanced discussions with a few cities, however their process was so slow that we got very near to the finals without any concrete validation.

The final was a 5 minute presentation in front of a big audience with some investors present.

Things got a bit more tricky when we got closer and closer to the presentation date. The rest of my team started to become less and less responsive. I ended up not being able to reach my brother's friend who had joined at the HackQC competition.

This quickly followed by my brother losing all interest in the competition and focusing on other stuff. We were left with myself and my brother's other friend (Félix) who joined in the very beginning.

He was also starting to slip out of the picture because nothing seemed to be moving forward, as I was the only one left coding. I wasn't very interested in that project either, however one thing I hate is half-backed projects (even more when they are public).

Our faces were plastered everywhere

I felt that it would have been a waste to stop so close to a conclusion. So I took it upon myself to jump start the project by coding the app's user interface, getting some branding going, and creating our business cards for the event.

As things started to pick up Félix started to become more and more involved (which was a blessing because he was the one pitching!).

We were still finalizing the PowerPoint the night before the presentation in the hotel room. After all this hard work we had something pretty solid (by my standards at the time, anyway). We've ended up winning fourth place in the competition:

Us receiving the 4th place trophy (again) with no money whatsoever associated with it haha

We went from a team of 4 to 2 people and were able to get that far. However, it was exhausting since I had to do so many different things that were not in my core zone of competency.

What I learned From My Last Hackathon

I learned two very important lessons during that adventure:

• Having motivated teammates is the most important asset in any endeavor. If we had everyone pulling their weight we would have had more chance to win!
• For a startup, having clients is the ultimate measure of success. We did everything right, except making sure that we had paying customers. In the end this is what kept us at 4th place.

We won a big $0 in that part of the competition, and once again I thought that was it. I had coded some cool Flask applications, went to the final of a big hackathon, and learned some valuable lessons. Until I realized...

How I Learned About Entrepreneurship at An Incubator

Being part of the finalists of Aquahacking automatically gets you a spot in one of the provincial incubators for startups, which happened to be Centech for us in Québec.

I didn't really know what an incubator was (except in a biological sense), so I wasn't particularly excited. We had to make a pitch for our "startup" to the incubator panels even though we had a reserved spot. I let Félix do it without me, as I had other stuff to focus on.

Centech is inside an old planetarium so it has that funky circular shape. It's a pretty cool place.

At first I didn't go too often to the entrepreneurial classes and I was starting to think that this whole hackathon-thing was becoming a huge time-sink. However, I stuck to it because Félix was very motivated by the whole experience.

So I decided to give it a serious shot. I started attending the entrepreneurial classes (which were amazing), I did the homework, and I tried really hard to make our sewage company work.

Lots of entrepreneurs in our 2018 cohort, try to find me!

Frankly speaking, it was amazing. It was genuinely fun to try and make something novel. And being mentored by people that had built incredible products that helped millions of people was incredible.

The class that I was in was also very motivating, as we had people from all backgrounds and oddly enough most of them were graduate students, like I was!

I really got the bug for entrepreneurship. It was like doing research, except I could directly see the results of my experiments in a matter of days. It was like combining the pleasure of discovery I had while doing an experiment with the freedom of programming for a side project.

However, after reading the books and learning the material, I realized that we'd done everything upside-down for our budding startup. We had built the technology before even validating that there was a sustainable business out of it (silly us!).

We were ready for our very first pivot, which in entrepreneurial jargon means tweaking your business in a significant way in order to not crash and burn.

How We Made Our First Pivot After Learning that Our Startup Idea Was Doomed

Our combined sewage overflow predictor was working great. However, no one was willing to spend money on it.

We were targeting cities in order for them to be able to proactively do something about the overflow of raw sewage into their rivers (which, by the way, is a worse and more frequent problem than you think). But these cities had such a long cycle to sell to that we would never be able to grow this business.

One thing that we realized during this project was that the majority of the data that was available for the competitions were in a very bad shape. It took us many hours of cleaning and we had to develop some very custom toolsets in order to make the cleaning efficient.

We had also talked to a few of the judges at Aquahacking and what they were most interested in was the portion of our business that related to data cleaning.

So that was it! We would become a data cleaning company. For about three weeks we were frenetically searching for customers, making plans on how to make this type of business work, and coding outlier detection algorithms.

This would have been us inside the datasets for the rest of our lives: Photo by [Unsplash](https://unsplash.com/@mkjr?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit">mkjr / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

However, after meeting with our mentors at Centech, we realized that what we were building was a service company. Almost no data is similar, especially when it comes from different sources.

The amount of domain expertise we would have to gain in order to be efficient in one industry would not necessarily transfer easily to another industry. There was a lot of manual work involved in this and all our ideas for making it more automated were failing.

Now, there is nothing wrong with making a service company. It's a great type of company if you are very interested in your industry. But we did some amount of introspection and we realized that we weren't really passionate about data cleaning.

We were passionate about automating work and improving efficiency through technology. Building a data cleaning company where most of the work would be manual and not very efficient wasn't very exciting for us.

We were ready to make our second pivot, which would be our largest so far.

How We Made Our Second Pivot

During the Centech program we had met two other entrepreneurs that had a problem that was complementary to ours. They had a lot of validation from potential clients whose problem could be solved by technology. However, they didn't have the technical skills to make the technology required to power their business.

I had helped them out a couple of times in order to get them started with building their web application since I'd already done something similar for EGC Labs.

Helping out other entrepreneurs without expecting something in return is very common in this type of environment. The more I helped them, the more we realized that we could get way more done if we were a team of 4 instead of two teams of 2.

We went for lunch to discuss what a potential "merger" of our two ideas would look like. After discussing for a week, we decided to ditch the EGC Labs project completely, as it had the smallest chance of success. Instead we would join forces with their idea, which was called GRAD4.

That was the second pivot for Félix and me. It meant completely dropping a project that was leading nowhere and joining another one that we were much more excited about.

Félix pitching our new company instead of the data cleaning one

During the next weeks, we were absolutely crushing it. We did everything right. We officially incorporated our company. We made a few plans as to what the actual application would need in terms of functionality so it would deliver value to our potential customers. However, we didn't wait for me to complete it to start selling it!

The other two co-founders were already on the road talking to people who'd showed interested. They were gathering checks for a 1 year subscription to our platform, which didn't exist yet. The $500 yearly subscription would start when we launched the product and we were very upfront that we were in the process of building it.

Getting people interested in your project is one thing, but getting paying customers before building a SaaS app is the holy grail of business validation. By doing so we were able to get about 15 checks that would help finance the development of the product.

We also won a $1500 elevator pitch competition around the same time because Félix was very focused on practicing his pitch.

All of these small wins compounded during the program and we ended winning a $15,000 prize at the end of the incubator called the Unicorn prize.

This was great, but more importantly we secured a spot in the next stage of the incubator which was the Propulsion program. This would secure us an office and some additional perks that would help our company succeed.

Cozy office in the basement of Centech. It was nice, but there was lots of noise because of pipes. You can see a wild cofounder working through the night.

What I Learned From My First Startup Incubator

During that part of our young company's adventure I learned a few important lessons:

• Clinging onto an idea because it was yours even though all analysis tells you it's a bad one is usually a bad idea.
• A larger founding team is more productive than a smaller one. It also allows for cheaper labor as no one is getting paid at the start.
• Asking customers to pay for an in-progress idea is not as difficult as you may think. If the pain is big enough for the customers, they are usually very supportive of having someone fix that mess. Even if the probability of success is low.
• The technology part of the business is not that important.

We Have Money, Now What?

We now had gathered a fair amount of money and we had multiple options in front of us:

• Either we keep the money and pay ourselves.
• We keep the money and don't use it in case we fail to make the app and we need to reimburse people.
• We use the money to hire people to speed up the development.

The first idea was wasteful, and it would decrease the probability that our company would succeed. The second option would just let our funds sit idle. So we decided to go for the third option.

How We Scaled Our Startup Past the Founding Team

During that summer of 2019, we made our first two official hires to help me with the development of the platform. They were software engineering interns from the ÉTS (École de Technologie Supérieure). One intern would be focused on the backend side while the other would be focused on the frontend side.

Our product was a simple CRUD application that would allow buyers who needed metal parts manufactured and suppliers of metal parts to find each other.

It was basically a sort of marketplace where buyers would create what is called a request for quote and the suppliers would create a quote to say how much they could build the part for. Pretty simple!

The technology we choose to use was the following:

• Django + Django REST API for the backend.
• React + Redux for the frontend.
• Bootstrap for the styling.
• Heroku to host both applications.
• GitHub for remote source control.

This was our setup at first. Credit: https://blog.usejournal.com/react-on-django-getting-started-f30de8d23504

Choosing the technology was up to me as the CTO, and I honestly decided to go with what I thought would be better in the long run. I was already familiar with Flask, however I knew a bit of Django too. Seeing that a lot of the functionalities I needed were already pre-built into apps made me lean toward it.

I chose React on the frontend side because I had played around with it 6 months prior and found that it was such an easier way to build applications than the traditional way I was used to.

However, in retrospect I think I would have greatly simplified the stack. I would have only used Flask for the following reasons:

• I was more familiar with Flask than with Django.
• We didn't need to have a separate frontend, as the application we needed to build was very simple. Simple templates would have been enough for a first proof of concept.

Just this would have been more than enough

However, we went with this tech and we learned a great deal in the process.

What I Learned During My First Months as CTO

One lesson I learned from this first foray into making an application customers would actually use is that overthinking scalability is oftentimes useless.

Working with what you are already comfortable with and delivering something as soon as possible is much more useful as you learn more rapidly. This is actually what is most important in a startup.

The more learning you can do (about the business, what customers want, how to talk to them) the more probable it is that the next thing you try will work.

After a few iterations, we were finally ready to launch our closed beta with the customers that had already paid for our service.

How We Did Our First Product Launch (Closed Beta)

We were able to make the first version of the application at the end of the summer of 2019 and launched it for our users (1 month later than we promised). It wasn't pretty and it was barely working.

We had to babysit our users throughout the whole process and the buyer section of the application wasn't usable. We had to do the work manually for all our buyers while the suppliers were able to create quotes.

What was great, though, was that we continued to be able to get checks from people who were interested which helped fuel development. We made a few mistakes on the hiring side, though. We hired a friend of one of the founders who, although experienced, was a jerk to the other more junior developers.

This was the first firing I had to do, and I'm glad I did it. Creating an enjoyable work environment is much more important than technical prowess, because at the end no one wants to work in a bad environment for long.

Having people stick around for the long run in a startup environment is crucial for the company's success. I believe it is one of the reasons our startup is still alive.

As development was chugging along we realized that we had to structure the company a bit more than what we were doing. Thanks to being next to so many startups and successful companies at Centech, we could learn from each other.

During that year, we focused on getting financing going (this is a super important part of business and should be prioritized). We also focused on getting some sort of marketing going, making actual designs that made sense instead of winging it, and making sure our team was staffed by full-time people instead of only interns.

We also moved from the basement of Centech to an office space with windows on the second floor which was actually pretty nice! We maxed out the capacity pretty quickly, though, and the founders had to start working in the dining area of the building so that the employees had more room.

This was way too crowded in retrospect, but at least the view was nice

What I Learned From My First Launch

I learned a great many lessons after our first launch:

Don't do an official launch. It's useless. We put so much pressure upon ourselves to impress the paying customer with a pompous launch, and we were afraid that they would be mad at us if we didn't deliver.

The truth is they didn't really care. When we sent an apology email saying that we had to delay the launch no one complained. I'm pretty sure they were actually amazed that we were able to get something up and running so quickly.

Even if you have paying customers for your SaaS application, prioritize doing manual work over building an application. In retrospect, I would have made a simple form where the buyer could upload a Zip file containing the request for a quote which would be sent to the founders' email address.

We would then send out this request manually to the manufacturers we knew would be interested in this type of work. That would have delivered value way faster to our users and released the pressure on development.

It would also have validated a lot of hypothesis we had that would have accelerated the development work.

Stay focused on very few things and make sure that this focus is explicitly written down somewhere. At some point I was building a blockchain-powered smart request for quote because it was hyped up by one of the co-founders who knew someone working with blockchain technology. That was a solid waste of time and I'm glad I killed that project soon after.

We were starting to pick up steam and we finally had something that we could show the world. It still wasn't pretty, however customers saw the value in what we were building and we knew better what was creating value and what was not.

We were ready to open our beta to increase the amount of users in our application!

How We Opened Up Our Product to More Users

After tweaking the platform using feedback from our early users, we now had a better understanding of what exactly we needed to build. We were now ready to increase the amount of people using our platform and start to increase the output of the sales (which the founders did).

This put more pressure on our application and we started to experience downtime. We knew that we had to improve the way we were building this product if we wanted to scale to more users.

We asked an experienced software architect, now part of the team full time (thanks Karim!), to help us out. This really gave us a solid direction to follow. Here is what we changed:

• We moved to AWS to have more control over the cloud environment.
• We moved to Gitlab to have an easier-to-use CI/CD environment.
• We added automated testing to our application.
• We started to migrate toward Material-UI instead of Bootstrap.

After improving the way we worked, we now had a fully working CI/CD setup and a more robust application that was rigorously tested. The amount of downtime we experienced was drastically reduced and developers were more confident about the changes they were making. It was a more enjoyable development experience, too.

Gitlab is a very enjoyable work environment and reduces a lot of the complexities with lots of tooling. Credit: https://about.gitlab.com/

What I Learned From My First Open Beta

During that period, I learned that the minimal viable product (MVP) phase of the product is necessary. But when transitioning out of it you shouldn't hesitate to ask for expert help.

We now had sales giving us more clients (which were still a bit difficult to get, but coming along at a constant pace) and the application provided more value than before.

We were ready to ask for our first real investment!

How We Got Our First Real Investment

We applied for a funding from Front Row Ventures which is a venture capital fund entirely managed by students and which only invests in student-led startups across Canada.

We met with the people from Front Row, and explained what we were doing and where we were going with all of this.

We ended up having to do a 25 minute pitch in front of a full panel of students who were asking solid questions about the business and the technology.

This was great because we knew that if we got the funding we would not only have the cash, but also new connections that could be there to answer questions and make strategic introductions for us.

It was great, some of these people went to the same university as I did!

Well, we ended up getting the funding and the people at Front Row were very helpful in many aspects of the company!

What I Learned From Getting Our First Funding

This was another important lesson I learned during that time: when choosing a funding partner, it's not only about the funding. It's also about how much help they can provide.

Front Row ended up opening many more doors for us and ensured that their investment had all the possible tools to succeed.

What Our Day to Day Routine Looked Like

Everything was going pretty well for us on the business side. However, the pace we were following was a bit worrisome. We were an archetypal startup where employees would come at the office from 9 to 5 and where the founders worked 80 hours a week.

Meeting on the weekends at the office to plan stuff out and clear up more tasks was routine.

I wasn't too happy with this because this type of work isn't sustainable in the long run – and I started to see signs of burn out in the others. We also weren't very structured, the documentation was poor, and we had almost no processes clearly mapped.

It was at that time that I started to read more about how to structure a company properly in order to maximize our chances of success (see readings at the end).

Then, out of nowhere, we started to hear about the possibility of a pandemic hitting our Canadian shores...

How We Reorganized When COVID-19 Hit

Some employees were very afraid of the virus and of getting sick. There were no cases in Canada yet, but some of the employees had family abroad in areas more advanced in the pandemic's course.

We started to think about what we could do and we realized that we didn't absolutely need to have people come in the office to do their work. All of the work could be done remotely just fine – it was just the culture that we'd set up that required people to show up from 9 to 5 every day of the week.

This type of schedule was directly taken from what we were all familiar with, but we realized that we didn't have to do like all the other companies we'd worked for.

We decided that we would allow everyone that wasn't comfortable going into the office to stay home. I personally decided to not show up to the office and most of our employees followed suit.

_As long as people had a the tools they needed, they didn't need to go into the office: Photo by [Unsplash](https://unsplash.com/@xps?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">XPS / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

This was great because we soon realized that a lot of the shortcomings of our company's structure were hidden by the fact that all employees were available in the office every day. Everyone was always trying to setup a Zoom meeting at random hours or calling at any time of the day to ask for operational tasks status.

We also realized that people had a hard time finding where all the information was, and many different people asked the same thing many times.

I decided to read a bit more about how to structure remote work efficiently so we read the remote playbook from Gitlab and implemented some changes:

• We removed the silos between the different teams by making all communication public and via written messages.
• We organized the documentation so that people would put their files in a shared drive instead of sending them on the instant messaging app.
• We instated a Kanban methodology for all departments, not just the people working on the technology since tasks weren't properly tracked.
• We reduced synchronous meetings by only scheduling those that were necessary and by having the results of the meetings communicated in one form or another.

This helped a lot! However, it took time before it really took hold. People were still having private messaging discussions when everyone could benefit from what was said. Synchronous meetings were still the default for a lot of people to share information.

Here are the co-founders trying to keep 2m distance in our first pandemic meetup (and photo shoot)

But it got better. By putting a lot of effort into making remote-work work, we were drastically improving our company's productivity to a level way above that pre-pandemic.

In a sense it was helpful that we were forced to experience remote work (as we were in full lockdown for a while) because it gave us the necessary buy-in from people that were skeptical that this was possible.

There was no other choice but to go all-in to remote work, otherwise the company would've just ground to a halt. We had employees to pay, so waiting the pandemic out wasn't an option.

In the business sense, we were very fortunate as our platform was useful for the manufacturing industry which couldn't do business in person anymore.

Some startups that we knew of weren't so lucky and their whole business was now impossible to operate within a very short time frame. Most of them had to close shop or do some radical pivot.

What I Learned From Pivoting to a Remote Company Structure

The first few months of the pandemic taught me some very important lessons:

Starting a startup is very, very, very risky. If you had started a ridesharing startup in 2019 and things were going fantastic for you, you would still have had to stop that business once the pandemic hit in 2020.

No matter how prepared you are, there are always risks and unforeseen events happening on a daily basis.

Working on the company is more valuable than working for the company as a founder. What I mean by that is spending time structuring the company and making adjustments to how people work in order to increase productivity is invaluable.

You can't expect employees to do that on top of doing their regular work. It's up to the founders to set up a structure that make sense and to always be improving it.

Remote work will improve your team's productivity compared to in person work (when possible) only if you take the time to make it work. Trying to reproduce an in-office way of working remotely will lead to an obvious decrease in productivity. Drastic changes needs to be made in order for this type of work to be useful and it requires a leap of faith.

We were still growing during that time as we were hiring more people to sustain our rapid pace. We also made a major pivot in how we were generating revenue by ditching our subscription-based model to a transaction fee model. This allowed our sales team to rapidly increase the amount of companies we enrolled in our application.

Our first version of the application started to show signs of not being optimally adapted given all the new information we'd collected from our customers. So we were working on revamping it with an improved design and user experience with a dedicated UI/UX team.

The Improved Version of the Application

We launched the revamped version of our app (this time without a hard deadline) and the reception was great. This is when I started to feel like we actually launched a real product and not a MVP to validate a need.

You could now see the part directly on the platform (we've used xeogl for that)!

The sales of our product increased dramatically as the user interface was great and the experience made sense to prospective users. We went on to do some more major refactoring and clearing up technical debt.

We knew that the added load on our platform meant that we needed to have something cleaner to work with. This was important as technical debt will always creep up and you can't just always build features.

We were slowly emerging from the bootstrapping phase of the company to more serious territory and it felt great. We made some more hires in the customer care and the marketing side. We improved month after month how the company operated.

Around that time, we decided to implement two systems that would improve our productivity:

Objective and Key Result system: This really switched our whole mindset from working long hours to working on objective attainment. By having concrete goals that would improve how the company was doing, it allowed everyone to focus on what really mattered.

It also allowed us to stop tracking when people were working or when they were taking vacations. As long as the objectives were worked on, it didn't really matter what the employees' workflows were (as long as they were not overworking).

EOS System from Traction: This system was a very good foundational system to ensure that everyone stayed aligned. It really improved how our meetings were structured and laid the foundations for the vision of the company.

I used to scoff at the thought of having a vision or core values. But after reading the book and implementing it, I cannot understand how we got as far as we got without one.

This aligned everyone to a level that we didn't think possible and allowed us founders to make better decisions for the company.

It now felt that we were really running at a solid pace. Every month we had major improvements or good news in the company. The whole startup thing felt easier and was more enjoyable.

What I Learned From My Second Product Launch

I learned another good set of lessons during the time of the launch:

Your job as a founder is to "elevate and delegate". At a certain point, if you are still working on the minutiae of the work you are wasting resources.

It is usually way more cost effective to hire someone else that is more competent than you to do the operational work and to move on to another position that doesn't have staffing.

By de-risking and laying the groundwork for a section of the company that is weak you are ensuring that it's worthwhile to hire someone and that this person has something to start with. This is priceless.

No one can work 80 hours a week on different job types effectively. We realized this when we were looking at what the weakest points of the company were. It was always the spot where someone that had 3 different hats was working because there wasn't enough time to do quality work.

If you are working on 3 different positions as a founder and you work 80 hours per week, it is the equivalent of working as a tired part time worker. The documentation will be poor, the process will be non-existent, and mistakes will start to show up.

As soon as we saw someone work more than 40h a week it was a big red flag that we needed to distribute the load onto someone else.

Part-time and volunteer workers are usually a waste of time. Once we were picking up more speed, we found ourselves constantly waiting for the part-time worker or the volunteer to finish their part of the work. This was holding us back so we made it a policy to not hire part time workers again.

It's different for interns though, as they have a well contained work arrangement. For instance, we currently have 3 interns working on various machine learning projects as part of their PhD. This is perfect because the work that is given to them is well balanced and we know what to expect.

Around the time of the new platform release, we started our first accelerator programs.

The NEXT AI and EcoFuel Accelerators

I didn't really know what an accelerator was at that time. However by being in two I quickly understood the difference between an accelerator and an incubator.

An accelerator's job is to give tools to an already up and running startup to accelerate their growth. On the other hand, an incubator is where startups usually begin.

One thing that is very useful in accelerators is that they provide startups they select with funding. By doing the NEXTAI and EcoFuel accelerators we were able to get $100,000 in total funding!

It was way more fast-paced than the incubator we'd been in. We had virtual classes with incredible entrepreneurs and got technical classes with researchers in machine learning such as Yoshua Bengio.

We also got to meet other amazing tech entrepreneurs living similar challenges in trying to get a startup to scale during a pandemic.

Here we are keeping the 2m distance for a photo shoot.

It's at that time that we officially founded the more "research-y" side of the company that dealt with making AI models and working on the data we collected. We staffed that section of the company with PhD students and graduate master's students (and me!).

It's also at that time that we decided to raise our seed round of venture capital (VC) funding. We made this decision because we knew that we had something great, however we were in the type of business where we needed to scale fast to deliver the most value to our customers.

The more people use the platform, the more valuable it is for the people using it. Therefore, getting funding to crank up the sales and marketing is a must. We put our CEO on that full time as it is indeed a full-time job.

Around the time when NEXT AI was ending, we had one of our first major financial drawbacks that would forever change the way we saw failure in our company.

We thought that, just like at Centech, we were in a very good position to get the financing that comes at the very end of the program. However, we were in the finalists but not in the top 3 winner startup.

This was a major blow as we thought we were very solid during the whole program.

After gathering more information about why we weren't shortlisted, we realized that there was a major communication gap between what the organizers of the program thought we were doing and what we were doing.

They didn't realize how advanced our product was and were not aware of all the cool AI modules we were building to complement our offering.

What I Learned From Our First Startup Accelerator

This is where we realized a very, very important lesson:

Other people's perception of your startup is as (if not more) important than what you are actually doing. We couldn't blame the program organizer for having the wrong perception about our company when they weren't even aware of most of what was happening with our company in the first place.

There was so much cool stuff happening everyday, but the number of things we publicly showed was thin in comparison.

This was problematic and could seriously handicap ourselves in the future. This is when I made the decision to celebrate the wins of the company publicly.

Every release of the product, I would publicly acknowledge my team's work on our social media. If we were passing major sales milestones, I would make a statement out of that. A major advance in the AI research of the company would be public within the week that it happened.

I used to hate posting on social media as it felt like I was bragging, but it was one of the most important change we've made so far. By celebrating our wins publicly, we've increased by a lot the likelihood of good opportunities coming our way. This is now a vital part of the company that we leverage every day.

With our new understanding of how to best promote the company and improve our probability of success, we applied to two other bigger accelerators (Creative Destruction Lab and MaRS) and got accepted!

The Current State of the Company

This last week of February was the best week the company has had, by far. User activity is way up and the amount of people involved in our project hasn't stopped growing. We are also in the final stretch of closing our financing round, which will allow us to accelerate our growth by a large margin.

However, it's not like it's all good and there is nothing to do now. One of the curses of starting to learn about a topic and making improvements in the way you work is realizing how much there is still to improve.

My company-improvement list on Trello never gets any shorter. Every time I finish a book, I have twenty new improvement ideas and every time I talk to a mentor, I have a dozen more. Even when I finish the implementation of one improvement, I have three more that spawn.

It's very comforting, though, to know that all of the work you put to improve yourself and your startup pays off. Also, realizing that you have created a company that can provide for other human beings is amazing.

I've made a lot of efforts to shed our old prototypical startup way of thinking. This means the following:

There Are Unlimited Vacations for All Employees

This basically means that we don't track anyone's time off. The only time I'm talking to an employee regarding vacation is when I feel they don't take enough time off.

There Are No Working Hours.

If an employee wants to work early morning or late evening, I don't really care (because I do too). As long as the objectives are reasonably met, there is nothing worthwhile to track.

There is No Bragging about the Amount of Work Someone Piles Up Allowed.

It doesn't matter. Only objectives matter. If someone is working an unusual amount of hours, we flag that to the human relations department and we initiate a proposal to find more personnel.

We Invest in Our Employees

We invest in them by buying books, courses, conference tickets, certifications or finding them mentors. Learning is a crucial part of the company's culture and it is heavily promoted. It's also very great for me because I can buy all the books I want on Amazon!

In short, I'm trying to build a company which I would have enjoyed working for. This is one of the guiding principles behind the choices I've made along the way and it really created something that I'm proud of.

My Advice to Aspiring SaaS Entrepreneurs

So that's how I ended up becoming the CTO of my company that has 20+ employees, all from doing random hackathons. It's been a wild ride and still is, but I would not trade this for any other job.

I want to conclude this section with a list of advice and tips for tech entrepreneurs (SaaS in particular) that I've learned along the way. I broke it down into subsections for convenience.

General Product Advice

Your Product is Way Less Important Than You Think

The value the customer can get from your product is what matters. If you can deliver the same amount of value to your customer in a simpler way than having a full blown application, do it.

You will learn faster and you will be able to create more value for your customers in return. At some point though, the only way to keep increasing the value you can deliver is to have a good application. At that point you should have a very good idea about what is important to put in it.

Validate the Need for the Product Before Thinking About a Solution

Spending time and effort on an application that your customers don't care about is the biggest waste of time you can have.

Validate with them every step of the way to see whether or not what you are doing is useful. Even at the expense of development time.

The Tech Stack you Choose is Less Important Than you Think

The most important concern is if you have enough knowledge to build something with the tech you choose, and if you can safely hire people to work with it.

Spending time finding the most optimal stack to work with is oftentimes pointless.

Do not Overcomplicate Your Application at First

Start with a good old monolith and gradually refactor it when needed. The monolith architecture will work like a charm for longer than you think!

Put the Minimum Amount of Features in Your App to Generate the Maximum Amount of Values for Your Customers

The fewer features you have, the less maintenance, fewer bugs, and less technical debt you will accumulate. If a feature is not used by your users, kill it and scrub it from your code base.

Talk to Your Customers

Spend as much time as possible with them and really learn from them. The knowledge you will gain will be a major competitive edge and will allow you to always deliver value to them!

At Some Point CI/CD and a Good Suite of Tests is a Lifesaver.

Not having to fiddle around with deployment and not having to worry as much that you introduced a regression in your code is liberating.

It allows you to become more productive and have a better understanding of the whole code base when you have to read test errors.

Monitoring is Super Important and Should be Implemented as Soon as Possible

Being able to know what is being used, what is the state of the application, and if there are potential problems is a must.

Not having monitoring tools is like driving in a forest road at night with your sunglasses on. It's a bit weird and generally not a safe way to get wherever you want to go.

DO NOT OUTSOURCE YOUR CORE COMPETENCY.

This advice is in all caps because I'm yelling it. If the core of your business is making a web app, make sure that you have everything you need in-house to make a web app.

Relying on outsourcing firms that don't have direct access to your customers or your reality is a sure way to mess the whole thing up. It's therefore extra important that you define clearly what is your core competency in order to not outsource it.

Artificial Intelligence Advice

AI is Great, but Delivering Value to Your Customers is Better

If you don't need AI to deliver value to your customers, don't put AI in what you give them. It will slow you down big time. However, if you validated that you indeed need some sort of AI to provide value to your customers, make that a top priority for your company.

Ensure That You are Collecting the Right Data for Your AI

This is especially important if you are working with partnering organizations as they often have no idea what is good data for a given problem. You need to figure out if the data is great for the problem you are tackling before getting more of it.

Start With a Linear Regression and Work Your Way to That Deep Neural Network with Thousands of Layers

Even if you have tasks for which you have enough data to attempt larger models, start with the simple ones. It will allow for rapid feedback on your data and will help you secure some baseline performance that can be used as benchmarks for the larger models.

Iteratively Improve your AI system and Don't Wait Until Everything is Perfect to Launch.

It's fine to label an AI system as Beta and start experimenting at a larger scale with users. This applies to any product you build, but I feel like this is worth mentioning again in the AI context as it is often forgotten.

Company Advice

Join an Incubator

The amount of coaching you will get – even from the judges before being accepted – is very important. They've seen thousands of startup ideas and they will be able to give you some very valuable advice.

Incubators are oftentimes paid by the government for every startup that they get in their program, which means it's a win-win situation for everyone.

Join an Accelerator After Joining an Incubator

This gives you additional resources and allows you to get very good coaching on very specialized parts of your business (like machine learning or financing). It is also a very good way to network!

Setup Your Core Values and Your Vision for Your Company

Having a vision is like a superpower. As soon as someone throws in that blockchain idea for the nth time you can throw it right back by saying that it doesn't fit the vision.

If someone has a rotten attitude you can easily show your core values publicly and correct course. The hiring and firing is much easier when all of this is setup and understood by the whole company.

Document Your Company's Processes as Soon as Possible

You will be surprised by how much processes you have even at an early stage. You will also be surprised by how little everyone is aware of it (including yourself!).

By documenting these processes you will be in very good shape to start improving and refining them to increase everyone productivity.

You Most Likely Don't Need an Office

If you are building a SaaS product, your stuff will most likely live on the cloud and your offerings will be purely software-based. Learn about how to setup a remote work environment efficiently and save on the office cost early on!

Meetings are Less Important Than You Think

Face to face synchronous meetings are not that useful. I've found that most of the time, just having a Google document that says what problem you want to fix in the meeting and distributing it to people you want to meet with is 99% of the job.

You will get a few comments on what to change, 3-4 asynchronous back-and-forth discussions, and voilà! Another problem fixed.

Meetings are Sometimes Necessary

No meetings whatsoever are not possible, though (I'm a hardcore asynchronous guy and even I need to admit that). If after sending that document you have 30 comments and you get to a stalemate kind of situation, it's usually time to ring the meeting bell and address the point of contention synchronously.

Most of the time, it's a matter of miscommunication. Having this synchronous back and forth allows the issue(s) to be resolved more efficiently.

Make Most Stuff in Your Company Public to All Employees

If something that is work related doesn't have to be private to a specific set of people, it should be public. By having the opportunity to jump in someone else's operational discussion, you can provide much needed feedback that will save lots of time.

Also, by having this whole bank of general knowledge available to everyone, you ensure that people are all aware about what is going on in the other departments.

Make Sure that the Private Stuff Stays Private

This goes both for security-related sensitive material and for private employee matters. If an employee tells you something personal, do not break that trust.

Continuously Improve Your Company's Structure

A company is an ever-growing organism. The structure that is best for today won't necessarily be the best in a month's time. It needs to be continuously tweaked and improved in order to maximize the work that the people working on it can output.

Beware of Working with Large Entities Like Cities, Multinationals, or Governments

These are slow and could end up suffocating your company. They will book meetings upon meetings to move the project forward by inches. Even if they pay you a lot, the cycle of learning you can do with them is so long that you will not have improved by much.

Working with smaller entities allows for more direct feedback. And if you can gather enough of them you can have a much more robust business. Resting on a thousand small pillars is more stable than resting on two huge ones.

Employee Advice:

Don't Hire Jerks Just Because of their Technical Skills

It's a big no-no. If you think about it this way, a person will stifle the productivity of everyone by souring the cultural soup.

If people are dreading going to work because of that one person, you will end up with more problems than what this person can fix with their code.

Cultural Fit is not an Option

Clearly check if the person has the technical abilities that you are looking for. However, check just as rigorously if the person as the right personality for your company.

Having someone clash with the company or not upholding one of your core values will do more harm than good.

Team Fit is not an Option

Make the teams an integral part of the hiring process. You will be surprised by how picky the team is and how rigorous they are in the hiring process.

It happened quite often that the person we were interviewing passed the technical interview and the cultural one, but didn't pass the team interview.

The rationale for rejecting a participant from the team was always valid and we couldn't believe we didn't catch it earlier in the process.

Neurodiversity Increases Productivity

You have to resist the urge to hire people that think exactly like you if you want to have a truly productive company.

By having people from different backgrounds, you will increase the chance of finding creative ways out of problems and you will reduce your blind spots by a lot.

Don't Try to Fit a Good Profile in the Company, Find a Good Profile for a Need

Always start by assessing what is your most urgent need and then find the best person to fill that position. By starting the other way, you will bloat your company with people that don't truly create value.

You Will Have to Fire People and it's for the Best

I've had to let a few people in the company go, and every time it was better for all parties. However, do it with respect. If you did all the work to bring someone on your ship, you should do all the work to bring someone out of it.

This means ensuring that this person understands why it's not a fit, that you gave enough warning signs, and making sure that this person has the support they need once they are moving away from the company.

Make Sure That Your Employees are Genuinely Happy

If someone doesn't feel good, talk to them and help them out. Wish them a happy birthday. Say thank you when they do something great. Coach them when they want to grow. Debug them when they make a mistake.

Having happy employees is one of your most valuable currencies as a startup and what makes working in one such a great experience.

Personal Advice:

Make Sure that the Founders or Executives don't Kill Each Other – and the Company

What do you get when you have a toxic startup culture of working insane work hours coupled with financial stress and customer problems? A good recipe for company failure.

Make sure to always reserve at least one hour per week where you don't talk about the company, but just check on each other and try to mend personal issues in the open.

Repeat After me: It's 👏 a 👏 Marathon 👏 not 👏 a 👏 Sprint

Insane working conditions cannot last. It's not if you will burn out, it's when.

If you cannot envision keeping the pace of work you currently have for the rest of your life, change it before it's too late.

I've seen too many startups crumble suddenly because of people thinking they can sustain having no time off forever.

Leave Room for Your Personal Growth

Learn about that one topic that is completely left field for your startup and enjoy it. Go ahead and network with people for your own benefit, it's okay. The more you grow as a person the higher the potential growth for your company.

Leave Room to Just Chill Out

Even if you enjoy working on your startup don't neglect the other aspects of your life.

It's fine to have other friends outside of work and it's fine to just unplug for a while. If you can't do that you have serious issue to fix in your company.

Have Fun

It's genuinely fun to build a company from the ground up. Enjoy the time working on that nasty bug that put the whole EC2 instance down. Enjoy your time calling this one customer that has nothing good to say about what you do.

Enjoy all of the little problems that will pave the way of your company. Because a startup can only do two thing: Die, in which case you will look back at those days with fond memory. Grow, in which case it will start to become something bigger than you and gain a personality of its own!

Useful (SaaS) Entrepreneurship Reading

The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses:

This book is a very simple read and taught me that cycling through hypothesis/learning is way more important than doing the most perfect thing right off the bat.

As a technical person that loves technology, I couldn’t understand why the tech was not at the forefront of every business discussion.

This book, with the clear example of bold tests that were done with real users, showed me exactly why a focus on building a product before understanding what the users will think of the product is a bad idea.

Traction: Get a Grip on Your Business

This book helped me make sense of how to structure our company once it has scaled past the founders. I’m at something like the sixth read cover to cover.

There is a lot of useful information and practical guidelines to use in order to really get a solid structure that make sense for the next growth phase.

It also helped create a sense of calm when thinking about the future because it increases your awareness of what will come in the future.

Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs

I read this book before reading Traction, however there are a lot of similarities between the OKR goal structure and the Rock goal structure from Traction. The basic idea is that you have limited time to work on goals/projects, so work on the most impactful ones and ditch the rest.

The idea of simply not thinking about the low priority objectives really creates a sense of space in your head. Knowing exactly what to focus on and having the liberty to think about how to get there also helped create an ultra-collaborative structure.

I use the OKR system in my personal life too. It really helps me reassure myself that I’m on the right path and allow me to say no to opportunities that pop up throughout year that are not aligned with my objectives.

Peopleware: Productive Projects and Teams

This was a very enjoyable read. It talks about a facet of software engineering that is often not taken into consideration, which is the people factor. I absolutely love the straight to the point organic writing style that the authors use.

Lots of examples are given and there is a significant supplementation of statistics along their argumentation that really help gauge what non conventional changes to implement.

DRIVE: The surprising truth about what motivates us

Drive is very closely related to Peopleware in the subject it addresses. Both of them help in figuring out how to create a work environment that is purposeful and that drive people to give their fullest.

I’ve learned a great deal about how much “carrot and stick” kind of reward/punishment comes into play in the traditional workplace and how it's not the optimal way to increase motivation.

It also allowed me to understand how I can push myself to accomplish my goals in a purposeful manner without having to bribe and trick myself.

Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale

This book is an extensive introduction to DevOps culture and is a good handbook to keep to consult when you're unsure about a certain aspect or situation.

It was the book that introduced me in more depth to that way of thinking and got me to really understand it more than on the surface level. It had some very neat examples of how all of the DevOps concepts tie up in the real world.

However, it’s quite a lengthy book. It is meant to be consulted in a non-linear fashion. I recommend keeping a copy at hand if you manage a technological team to get some ideas about what to do in a given situation.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

I read the Phoenix Project a while after having read Effective DevOps. Effective DevOps gave me a deeper understanding of the movement, but it’s the Phoenix Project that really made everything “click”.

It’s a novel, but explained in such an organic way that it could have been a biography. I read the whole thing in 2 days over the summer as I was very engaged with the protagonist's struggle with inefficient process and “impossible” goals to meet.

After reading it I felt way more confident that the changes I was making to my organization were the right ones.

If I had one book to give to a non-tech manager to make them understand how to make a tech department fail and how to make it thrive, it would be this one.

Designing Data-Intensive Applications

This book was so densely packed with information gained from working with very difficult problems that you probably need to re-read it from time to time while you also work on difficult problems.

I’ve learned a lot, both in the inner design of the behemoth of the internet and how much these behemoths were built by facing a constant stream of problems.

The sheer amount of tradeoffs, learning, and ambiguity that takes place in systems at huge scale was staggering. It helped me prepare and better react when I hit various problems in my tiny (in comparison) systems I’d been building.

Likewise, this is the kind of book that should be read periodically while building something that is in the process of scaling.

Forge Your Future with Open Source: Build Your Skills. Build Your Network. Build the Future of Technology

This book is one that really helped me better structure our remote company so we could hit our business objectives and help our employees feel productive and happy.

I drew a lot of inspiration from how open source projects were structured and made quite a lot of changes in that sense. It also helped me understand and appreciate a bit more about how open source projects work.

Principles by Ray Dalio

This is an incredible book with an insane amount of tips from a successful entrepreneur in the financial sector.

The amount of useful content in there is staggering and will require multiple reads in order to extract it all. If you are looking for new ideas to make your organization more efficient, better at problem solving, or stimulate growth, it's a must!

Delivering Happiness: A Path to Profits, Passion, and Purpose

A very beautiful book by the late CEO of Zappos. It's a humble book filled with good learning and takeaways by Tony Hsieh in his entrepreneurial journey.

The most important part here is the focus on making sure that the culture was right, as he had two main company successes in his career: One with LinkExchange that had no focus on the culture and another one with Zappos which was heavily invested in it.

The latter is arguably the stronger business.

Reaching Out

If you are interested in learning more about my company, you can check our website. If you have questions feel free to add me on LinkedIn or Twitter to chat :)

I hope this was helpful!

In this article, I’ll share my journey of building an API business, the technology behind it, and how to build your own API business in the future.

First, a little bit about the business I've built: Listen Notes is a podcast search engine that allows people to search nearly two million podcasts and more than 89 million episodes by people or topics. We also provide a podcast API for developers to use, which is called Listen API. It has become a core part of our business.

An accidental API business

I left my previous failed startup in September 2017. After a few days of tinkering, I picked up one of my fledgling side projects to polish the UI a bit.

That side project was Listen Notes, a podcast search engine website, which was just a single page React JS app running on three $10/month DigitalOcean droplets.

Little did I know a few years ago that my small, neglected side project would turn into the helpful business it has blossomed into.

An early version of Listen Notes

I continued to work on Listen Notes full-time and incorporated Listen Notes as a Delaware C-Corp in October 2017. One of my goals was to experience as many facets of business as possible, rather than just writing code behind the scenes.

My initial plan was as follows: (Don’t laugh at me!)

• Build a podcast search engine website and make some money from advertising, just like Google. Simple!
• If this Listen Notes thing doesn’t work in two or three months, then I’ll run out of cash, and I’ll go into credit card debt to keep going for one more month or so. If it still doesn’t work, then I’ll have to find a full-time job. Although Jeff Bezos’ parents invested $300,000 in early Amazon and Mark Zuckerberg’s parents loaned $100,000 to early Facebook, not every family is able to casually toss six figures of cash at web projects.

Then something happened.

On November 20, 2017, I got an email from the developer of a new podcast app, who asked if Listen Notes provided an API. He wanted to be able to search episodes in his app, but he didn’t want to build the entire backend.

I asked a few questions (for example, how would the endpoints look, what data fields did he need, how much was he willing to pay…). I got his answers. Everything was in an email thread within a couple days.

On November 30, 2017, I quickly implemented three endpoints (GET /search, GET /podcasts/{id}, and GET /episodes/{id}), which were basically three Django views.

I Googled “API gateway” or something like that and found a service called Mashape, which was an API marketplace that handled payment, user management, and API documentation.

So I put my three endpoints on Mashape and created two plans there: FREE and PRO. I emailed the developer back to tell him the API was ready to use.

The email thread that prompted me to build Listen API

Then nothing happened. The podcast app developer didn’t use our API and instead phased out their project.

Eventually, I moved on to primarily focus on the development of listennotes.com. The API was basically in self-driving mode on the open web. Anyone who happened to discover our API could sign up, without talking to any human beings.

On January 14, 2018, I got my first paying user. A few more paying users arrived that same year.

The email notification I received for my first paying user

Wait, what is RapidAPI? Well, Mashape was acquired by a startup named RapidAPI. They didn’t rebrand Mashape to RapidAPI completely until mid-2018. Startups typically don’t do things in a clean and methodical way, which is totally understandable.

Then something happened.

There was an outage on the RapidAPI end on November 29, 2018.

The email I sent to people in RapidAPI when the outage happened

RapidAPI had performed a big backend upgrade around that time. As an engineer, I totally understand that outages happen, especially when making huge changes in the backend. But I felt helpless because their customer support didn’t reply to my email. Phone call didn't work, as expected.

Usually their customer support was very responsive. Perhaps it was the holiday season and people were on vacation.

So I used hunter.io to find work emails of individual RapidAPI employees, the CEO, as well as the CTO. The issue was finally resolved, many hours later. In other words, our API was completely unusable during those down hours. I felt very sorry for our paying users.

Then around mid-February 2019, RapidAPI had billing problems and failed to pay us a few thousand bucks. Our paying users paid RapidAPI first. RapidAPI took a 20% cut. Then they paid the remaining 80% (minus PayPal fees) to us.

After several back-and-forth emails and phone calls, we finally got our payment. It’s understandable. Again, startups make mistakes.

In late February 2019, I decided to build our own RapidAPI replacement, for a few reasons:

• Our API revenue became nontrivial. The 20% cut from RapidAPI was a bit too much for us.
• We wanted API requests to hit our own servers directly, thus lowering latency for our users.
• I didn’t want to feel helpless when RapidAPI had outages. Overall they did a good job running the service. But I wanted to control my own destiny.
• I wanted to contact my API users directly. Using RapidAPI, API providers like me didn’t have access to our users’ email addresses. It’s understandable. It’s like the “Uber for X” companies that don’t want workers and customers to bypass them and strike deals under the table. Marketplaces don’t want users to skip the middleman’s commission fees.

In addition, I vowed to do two things really well for our new API system:

• We must provide great customer service to our paying users.
• We will give customers a very stable & reliable backend service.

After 30 days of hard work, we launched Listen API v2 on March 27, 2019. The legacy API hosted on RapidAPI became Listen API v1, a version we won’t add new features to but don’t want to shut down because some apps are still using it as of December 2020!

We continue to improve our new Listen API v2 by adding new endpoints, new data fields, improving operational efficiency, as well as spiffing up the user dashboard and our internal tools.

Things are picking up speed gradually. I’ve been happy since then.

So, that’s the journey of Listen API so far.

Note: Although we decided to move on from RapidAPI, I still think it’s a great service. Startups all make mistakes in the early stage. They fix things and continue to improve their service, which is great!

The technology behind Listen API

Developers can use our API to search podcasts and fetch detailed podcast-episode metadata. To make this whole thing work, we need to make sure a few core components are in place.

Listen API's main components and the technologies used

Datastore and search engine

This is a shared component with our website. Therefore, I didn’t need to change anything in the datastore and search engine when building our API infrastructure.

We use Postgres as our main data store (for example, for podcast metadata, user accounts, and so on), and Elasticsearch as the search engine.

I wrote an old blog post with the details of the entire tech stack.

Internal tools and processes

If you’ve worked at any web companies, you probably know what I’m referring to here.

It’s rare for an Internet business to be 100% automatic. A company always needs to build tons of internal tools and set up manual processes to keep the service functional. That’s why companies like Retool have such a high valuation nowadays.

Companies are investing big money in internal tools that are invisible to end users:

Percentage of team's time spent on internal tools. Credits: Retool

To start our API business, we needed to build (at least) two types of internal tools:

• For data operations: We needed the ability to keep the podcast metadata up-to-date, fix corrupted metadata, plus review and approve any changes made by users.
  Additionally, we required a framework that handled new, rare edge cases of corrupted podcast data along the way. To some degree, building a software product means handling tons of edge cases for a very long period of time (like, years), rather than launching new features every day.
• For user operations: We required the ability to suspend a bad user’s account, as well as immediately look up all information related to a specific user who contacted us for a specific issue.
  Plus, we had to be able to quickly evaluate if “it’s our fault” (server-side errors) or “it’s their fault” (client-side errors) when users complained.

Internal tools are used by employees inside the company. Some of those tools are fully automated, such as cron jobs that perform scheduled tasks. But many tools should be used manually by human employees, for example when inputting a user’s ID number and clicking a button.

Most of our internal tools have ugly web UIs, with default Bootstrap styling :)

A portion of our internal tool’s UI that allows us to suspend an API user’s account.

Fortunately, our API shares many internal tools with the website. So we didn’t need to build too many new things here.

The analytics and billing system

The pricing model of an API is typically usage-based. Check out some real world examples:

• https://www.twilio.com/pricing
• https://sendgrid.com/pricing/
• https://cloud.google.com/maps-platform/pricing/
• https://www.microsoft.com/en-us/bing/apis/pricing

It’s a must to track how many requests a user uses in real-time. We use Redis to keep track of such stats and periodically dump into Postgres for persistent storage.

What happens if our Redis has an outage? We might temporarily lose some tracking stats. In this case, we have an internal tool to sync stats from raw Nginx logs.

We have to change billing plans without affecting existing users. For example, if we raise prices, existing users should still enjoy the benefit of the old plans. If it’s not done right, it’s easy to have inconsistent states across the board, and angry users getting charged the wrong billing plan!

Payment failures, a very common occurrence, must be handled gracefully. We can’t just suspend users right away. We need to be able to notify ourselves that “this user failed to pay” and notify the user that “you failed to pay.”

After a few retries, we suspend users manually — well, we could’ve automated this last step. But we don’t suspend users often nowadays, so it’s okay to do so manually. There’s no need to make everything perfect (at least for now).

We have a dashboard (God’s view) to see how many requests each individual user uses in the current billing cycle. And we are able to review raw logs for each user from a web UI, without manually pulling log files from S3.

Stripe and PayPal (via Braintree) are our payment processors. Most of our international users use PayPal.

Finally, putting all of these factors together, we can calculate the actual amount of money that a user should pay us in real-time, based on their usage. We run async tasks via Celery to charge due bills.

What happens if a user unsubscribes in the middle of a billing cycle? We charge them prorated rates, based on time and usage. Users don’t need to pay a full month’s fee in those instances.

API Servers

We run Django apps to serve API requests. Each endpoint is a simple Django view. A Django middleware verifies if a request is legit, then generates a log or rejects the request right away.

We cache response data per API key + unique URL in Redis. In general, our API performance is pretty good.

We use Nginx as a load balancer and provision multiple API servers. It’s straightforward to do rolling deployment here, with a bunch of sanity checks to ensure the API is functioning.

Generally speaking, the easy and robust deployment process increases my confidence to make incremental code changes often and to deploy frequently.

An API endpoint is RESTful and returns a JSON response, pretty standard nowadays.

User Dashboard and API Docs

Each API user can access a dashboard on our website to learn the amount of requests they’ve used in the current billing cycle and view recent raw logs. They can also update payment methods, create or reset new API keys, set up webhooks, and add coworkers to the same API account.

Listen API's user dashboard

API Docs is probably the most important UI for an API business. Therefore, many API companies employ a whole team of full-time engineers to build and maintain “merely” the API Docs page(s).

An API Docs page is not simply a full page of English words. It must show code snippets for different programming languages.

Users have to be able to run your code example directly from the page. You are required to design a repeatable process (no matter if it's automatic or manual) to keep the documentation in sync with your code. There are plenty of nuances.

We spent a lot of time and energy building and iterating multiple versions of our API Docs page. Following is the end result:

Listen API Docs Page

Initially, we tried a few open source solutions for the API documentation. It’s quite time-consuming to understand an open source project well enough to customize it. Ultimately, we decided that it would be faster to build the page from scratch rather than customizing an open source solution built by others.

Our API Docs page is basically a React JS single page app.

We codify all endpoints, response data schema, and example response in an OpenAPI spec. The React JS app of the API Docs page reads from our OpenAPI spec directly.

The side effect of using OpenAPI is that we can easily integrate with tools like Postman, because OpenAPI is a (relatively) widely adopted standard for API documentation nowadays.

Why Listen API works

Listen API has been a nice business for me so far.

But don’t expect me to share revenue numbers publicly :)

Some companies are doing this open startup thing, sharing every single business metric to the public, which is great.

But we shouldn’t blame the majority of companies (including my small company Listen Notes, Inc.) who don’t want to share business metrics publicly.

Not everyone is comfortable being naked in public, literally or figuratively.

Similarly, there’s lots of business advice (or cliches) that you don’t have to follow.

• You don’t have to find a cofounder - having a horrible cofounder is way worse than not having one.
• You don't have to reveal your revenue to public or do any "open startup" thing. No pressure. Don't feel guilty if you are not doing what other cool kids are doing. You run your own company. You make your own decisions.
• You don’t have to do XYZ that a Twitter VC philosopher urges you to do in a fortune-cookie-like tweet.
• You don't have to be 100% bootstrap nor 100% VC-backed. Many things are not completely one way or the other. Usually, there's middle ground.
• ...and the list goes on.

The bottom line is, not one is absolutely wrong or absolutely correct. Each individual's vision/knowledge is limited. Each person's preferences might be very different.

An API business may be too obscure to most people in the world, but I like my API business very much. People from big companies (like Apple, Amazon, or Microsoft) may examine my business and deem it “cute”. But I would consider it a success for me personally.

And success is relative. The key is to bring happiness to customers (by saving them time and money and helping them solve problems), myself (a professional achievement), and my family (by keeping the fridge full).

So why does the Listen API work?

Demand and MVP

I didn’t build a solution to find problems. It was the problem (a podcast app that wanted to add search functionality) that found us—and we built a very simple solution at first.

We didn’t spend months launching the API. We spent a couple of hours. It costs at least $100 per hour to hire a not-so-bad engineer in San Francisco, so the cost of launching this API MVP was approximately $200. Even if it were $2,000, I'd still think it was worthwhile.

Two reasons why we were able to launch an MVP quickly:

• The heavy lifting part of building a podcast database, search engine, and data operations tool was already done, because of our podcast search engine website.
• Mashape / RapidAPI existed to provide a plug-and-play solution for us to manage users and create paid plans without writing code on our end.

However, in hindsight, it’s actually very common for a commercial search engine to license their tech (via API or other ways). Some examples:

• Yahoo Search was powered by Google circa 2000, and is powered by Bing today.
• In the early days, Baidu's only business model was to put a web search on some Chinese portal sites
• Today, Bing provides a bunch of search APIs.

By launching an MVP fast, we were able to get feedback early, especially after getting the first paying user only a month or so after launch.

Good documentation

User feedback proves that our API Docs page plays an important role in customers' decisions to use our API. There must be a reason for API companies to employ a whole team of engineers “only” to maintain their documentation pages.

Great documentation builds trust.

Stable backend service

Stability is the essential base of an API business’ Maslow’s hierarchy of needs. If an API is not stable at all (for example, it has frequent outages or runs very very slowly), it can't be used.

However, it’s boring to perform work to improve backend stability. Most tasks to stabilize backend services are preventive, including extensive monitoring and alerting, the process to deploy code with confidence, end-to-end regression tests, and so on.

No news is good news.

No outages are great news.

We use Statuspage.io to hook up our Datadog metrics to build a status page: listennotesstatus.com.

System status page of Listen Notes

Here’s hoping that the status page will convince our prospective users to try out our API :)

Excellent customer service

We are all customers of someone else’s products and services. We have all been frustrated with poor customer service at some point in our lives. It’s obvious that great customer service goes a long way — RIP, Tony.

Many people are likely not aware that you have to pay AWS big money to access better customer service!

Our customers don’t only pay us for using our API, an online service. They also pay for being able to get high-quality customer assistance from real human beings. In our case, it’s me, the person who built this thing.

I use Superhuman to process emails promptly and efficiently. And I’ve got a ton of prewritten email templates to handle the most popular customer support tickets. Oftentimes I can reply to an email within 5 seconds, using CMD + K to select an email template.

Invest in internal tools and processes

For knowledge work, it’s possible that one single person (or a tiny team) can create 10x, 100x, or even 1,000x more value than a big team.

Let’s look at an extreme example: book publishing. It’s (almost) impossible to hire 10,000 good writers to collaborate on one book together and hope it’s “better” cohesively than Harry Potter, written by a single author.

JK Rowling, a single person, created way more value (in terms of measurable dollar amount and unmeasurable happiness, good times) than most companies with hundreds of employees in the world.

Eventually, the software business would grow in a similar way.

We already witnessed the 13-employee Instagram get acquired for $1B in 2012. When will we see a $1B+ software/internet company with 5 or fewer employees achieve the same feat?

Great internal tools and processes provide leverage to enable a tiny team to be super-efficient. This is easy to understand. We human beings already built a lot of tools to greatly extend our physical/mental limits, for example bikes and cars (versus walking), computers (versus manual calculation), and so on.

Given that it’s (almost) impossible to 100% automate an Internet business, we have to improve the efficiency of manual operations. It’s a great investment to increase human operators’ productivity.

Tidbits of running Listen API as a business

Here are some things I didn’t know before…

Anyone can sign up => Submit your application first

A few years ago, I noticed that certain APIs required me to submit an application first, describing my use case, before giving me an API key.

I didn’t understand the rationale back then.

After running my own API business, now I understand.

The Internet is huge. The world is gargantuan. There are good people and bad people. If the API you provide is useful, some folks will try to abuse your API.

That’s what happened when we initially allowed anyone to create an API account. We were seeing users creating dozens of accounts in order to get around the free quota limit.

Today, we require people to submit an application first. We get a notification via Slack. Then we use our internal tool to review and approve or reject the application. The applicant receives an automatic email. On our end, it’s two or three clicks to finish all these operations.

To assist our review process, we use a bunch of heuristics:

Did this user previously create multiple accounts?

Is this IP address a well-known spammer discoverable via stopforumspam.com? (hint: there's an API for that)

And so on…

Again, we are seeing new edge cases from time to time. Yet we are also learning how to handle those unique cases.

Ideal customers and interesting customers

Our best customers are mostly startup founders who have been in business for quite some time.

They can make decisions on their own. They understand the value we provide. They have the power to finalize purchase decisions. And they are competent enough to read our documentation autonomously and ask very few questions — or they don’t even talk to us at all.

On the other hand, people from well-funded VC-backed startups or huge companies (some of the biggest companies in the world) oftentimes ask for a discount or free trial, which we don’t have. Why? I don’t have a good answer here.

Of course, there are always exceptions.

Dev shops and coding bootcamps

Many of our users hire freelancers or dev shops overseas to build apps and websites.

Generally speaking, developers from dev shops are not as good as in-house developers. Although not 100% true, the chance is quite high.

In essence, a bunch of my customer support replies are to teach Computer Science 101 . Sometimes they sent code snippets in PHP (or a language that I don’t know) to ask us to debug it via email.

I understand that some of those developers from dev shops are fresh out of coding bootcamps (or the dev shop itself is a coding bootcamp). Most of the time I will Google for them and send them a StackOverflow link or something like that. But occasionally, if I was in a bad mood, I would not reply to the “help me debug my PHP code” emails from FREE users who don’t pay us.

Also, quite a few coding bootcamps use our API to teach students how to write code, which is great. In real-world web projects, you can’t avoid using third-party REST APIs. Teaching new programmers how to talk to a REST API is necessary.

API is a slow business

Usually it’ll take a user a few months to start paying us.

They need to add a big product feature or even build an entire app first. Then they need to do some marketing and get some traction. Finally, they pay, or they give up and shut down the app.

We definitely should think about how to help our users build product features fast.

Stripe is doing a great job in this area. They built a lot of nice UI components that developers can directly use without writing tons of code, like Checkout.

API is a stable business

Our churn rate is quite low. People spend many months building an app using our API, so it’s unlikely that they’ll switch to something else overnight.

I’m happy with that fact.

Meanwhile, I’m also very bullish on all the other API businesses out there, like Stripe, Plaid, and Twilio. (This isn’t investment advice, but look at the stock TWLO.)

Start with whales, then diversify

At the early stage, there might be a few user “whales” who account for a big portion or even most of the revenue.

Don’t panic.

Having revenue is still better than not having revenue at all.

We are not in a position to be picky at the early stage. We can diversify along the way.

I like reading S-1s.

It’s not uncommon to see some SaaS or API companies with a few whales when they went public. If they lost one or two such whales, their revenue would drop 10%, or even 20%+ immediately! Well, they are already a public company. No need to worry about them. They know what to do next.

Pricing is a work-in-progress

We are always experimenting with new pricing. Similar to building software projects in general, pricing is always a work in progress.

We allow old users to stick to the lower pricing they obtained when they signed up. Any future price changes won’t affect existing paying users.

I know that select pricing experts would warn me that I leave money on the table by this practice. But I feel thankful for customers who stand by us for so long. I want them to enjoy the low pricing as a benefit.

By the way, ProfitWell has great resources regarding pricing.

Haters / irrelevant critiques

You may have seen this theory: When you have haters, you’re doing something right.

There’s a similar quote from Zeng Guofan (one of the most important military leaders and politicians in the 19th century China):

不招人妒者皆庸才. “If no one envies you, then you are incompetent.”

Side note: You can find Zeng Guofan’s wisdom inside many airport bookstores in China. He would have been a great Twitter user and beat those Twitter VC philosophers if he were born in our time - it's hard to beat a historical Chinese figure in the game of fortune cookie :)

If your project is visible on the Internet and gets a bit of traction, some people will hate you for no particular reason.

Once you offer a paid service, you’ll never provide a price that is low enough to make everyone in the world happy. No, $1.00 USD is not cheap at all in many places in the world. People who are not your target users will complain about your pricing.

From my experience, it’s safe to ignore most critics, advice-givers, and suggestions from non-users. Sometimes people try to compare two things with similar names.

For example, if you search “podcast API” on Google, you’ll find a few other APIs with “podcast API” in their names. However, if you spend a few minutes skimming the documentation, you’ll find obvious differences. It’s like comparing two people with the same first name and family name who are two completely different individuals after all.

The only critiques or suggestions I care about are mostly from our users. I can see their API usage. I know they are expressing meaningful facts. So I listen to them.

So are you interested building an API business?

Nowadays, the “passion economy” or “creator economy” is hot.

Who are creators? Writers, podcasters, streamers…

Don’t forget that software developers are also creators!

If you already run a website or have some interesting data, you may start an API business as well.

Thanks for reading this long article :) Let me know what you think: wenbin@listennotes.com. And you can read more of my posts on my blog.

From implementing favicon to deploying to a cloud platform, I will share everything I learned. I'll also share extensive code snippets, best practices, lessons, guides, and key resources.

I hope something here will be useful to you. Thanks for reading. ❤️

Table of Contents

• Introduction
• Finding Ideas
• The Stack
• Repo
  • Start full-stack development locally
• Client
  • Npm Script
  • Environment Variables
  • Webpack & Babel
  • Web Performance
  • Differential Serving
  • Fonts
  • Icons
  • Favicon
  • API Calls
  • Test Production Build Locally
  • Security
• Design
  • Modular Scale
  • Colors
  • CSS Reset
  • A Styling Practice
  • Layout
• Server
  • File Structure
  • Npm Script
  • Database
  • Creating Table Schemas
  • Dropping a database
  • Crafting SQL Queries
  • Redis
  • Error Handling & Logging
  • Permalink for URL Sharing
• User Authentication System
• Email
  • Implementation
  • Email Templates
  • How to get one of those hi@example.com
• Tenancy
• Domain Name
  • How to get one of those app.example.com
• Deployment
  • Deploy Nodejs
  • Deploy Postgresql
  • Setup schemas in production database
  • Deploy Redis
  • File Storage
  • Deploy New Changes in Back-end
• Hosting Your SPA
  • Deploy New Changes in Front-end
• Rich-text Editor
• CORS
• Payment & Subscription
• Landing Page
• Terms and Conditions
• Marketing
• Well-being

Introduction

I switched careers to web development back in 2013. I did it for two reasons.

First, I noticed I could get lost in building customer-facing products among all the colors and endless possibilities for interactivity. So while being reminded of the trite "Find a job you enjoy doing, and you will never have to work a day in your life", I thought "Why not make this a job?"

And second, I wanted to make something of myself, having spent my teenage years inspired by Web 2.0 (Digg.com circa 2005 opened the world for me!). The plan was to work on the latter while working in the former.

Turns out, though, that the job and the 'JavaScript fatigue' ensued and wholly consumed me. It also didn't help that I was reckless in my pursuit of my ambition, after being influenced by the rhetoric from 'Silicon Valley'. I read Paul Graham's Hackers & Painters and Peter Thiel's Zero to One. I thought, I'm properly fired up! I'm hustling. I can do this too!

But nope, I couldn't. At least not alone. I was always beat after work. I couldn't find a team that shared my dreams and values.

So meanwhile, I rinsed and repeated less than half-baked projects in my free time. I was chronically anxious and depressed. I mellowed out as the years went by. And I began to cultivate a personal philosophy on entrepreneurship and technology that aligned better with my personality and life circumstances – until September 2019.

The fog in the path ahead finally cleared up. I got pretty good at it – the job then became less taxing, and I'd reined in my 'Javascript fatigue'. For the longest time, I had the mental energy, time, and the mindset that allowed me to see through a side project. And that time, I started small. I believed I had this!

I was wrong.

Since I had been a front-end developer for my entire career, I could only go as far as naming the things that I imagined I would need – a 'server', a 'database', an 'authentication' system, a 'host', a 'domain name', but how... where... and what...I..I don..I don't even... ?

Now, I knew my life would have been easier if I'd decided to use one of those abstract tools like 'create-react-app', 'firebase SDK', 'ORM', and 'one-click-deployment' services. The ode of 'Don't reinvent the wheel. Iterate fast'.

But there were a few qualifications I wanted my decisions to meet:

• No vendor lock-in — This ruled out using the Firebase SDK all over my codebase. This included 'create-react-app', because ejecting it forced me to inherit and maintain its massive tooling infrastructure.
• Simple & Minimalistic — Cut having to learn new opinionated syntax and patterns. This ruled out 1) Project generators that output complex architecture and layers of boilerplate codes, 2) Using third-party libraries such as 'knex.js' or the 'sequelize' ORM.
• Pay-as-you-need — I wanted to keep my operating cost proportional to the usage level. This ruled out services such as 'one-click-deployment'.

To be fair, I had the following things going for me:

• I was building a simple SaaS.
• I was not anxious to scale, dominate, disrupt etc.
• I was still holding my day job.
• I had accepted my odds of failure. ?

Also keep in mind that:

• This was a one-man show—design, development, maintenance, marketing, etc.
• I'm not a 10x rockstar full-stack programmer.

Most importantly, I wanted to follow through with a guiding principle: Building things responsibly. Although, unsurprisingly, doing so had had a significant impact on my development speed, and it forced me to clarify my motivations:

• If I had to ship something as soon as possible, unless it was a matter of life and death, then I probably wasn't solving a unique and hard problem. In that case—assuming I was still at my day job and had zero debt— What was the rush?
• And second-guessing from the ethical perspective: Was it even a problem that needed solving? What would be the second-order consequences if I solved it? Could my good intentions be better directed elsewhere?

So what follows in this article is everything I've learned while developing the first project I ever launched called Sametable that helps managing your work in spreadsheets.

Let's get to it.

Finding Ideas

Well, first of all, you need to know what you want to build. I used to lose sleep over this, thinking about and remixing ideas, hoping for eureka moments, until I started to look inward:

• Build things that solve problems that you encounter and piss you off frequently.
• Solve the so-called 'pain points' or 'frictions'. Go outside, don't stop listening to people and learn from them.
• Be an expert in your domain. Feel its pains. Maybe solve one of them. Seems to me lots of founders founded company related to their domain on which they have built their career and social network.

The Stack

How your stack looks will depend on how you want to render your application. Here is a comprehensive discussion about that, but in a nutshell:

• Client-side rendering(CSR); SPA; JSON APIs — This is perhaps the most popular approach. It's great for building interactive web applications. But be aware of its downsides and steps to mitigate them. This is the approach I took, so we will talk about it in a lot of detail.

• Hybrid CSR; Both client-side and server-side rendering(SSR) — With this approach, you still build your SPA. But when a user requests your app, for example, the homepage, you render the homepage's component into its static HTML in your server and serve it to the user. Then at the user's browser, hydration will happen so the whole thing becomes the intended SPA.

The main benefits of this approach are that you get good SEO and users can see your stuff sooner (faster 'First Meaningful Paint').

But there are downsides too. Apart from the extra maintenance costs, we will have to download the same payload twice—First, the HTML, and second, its Javascript counterpart for the 'hydration' which will exert significant work on the browser's main thread. This prolongs the 'First time to interactive', and hence diminishes the benefits gained from a faster 'First meaningful paint'.

The technologies that are adopted for this approach are NextJs, NuxtJs, and GatsbyJs.

• Server-side rendering and 'sprinkle ✨ it with Javascript' — This was the old-school way of building on the web!—Use PHP to build your templates with data in your server, then bind events handlers to the DOM with jQuery in the browser. This approach might have been ill-suited to build the increasingly complex apps that businesses have asked for on the web, but some technologies have emerged to warrant a reconsideration:

  • https://stimulusjs.org/
  • https://github.com/turbolinks/turbolinks
  • https://github.com/phoenixframework/phoenix_live_view
  • For more, check out this twitter thread

To be honest, if I was more patient with myself, I would have gone down this path. This approach is making a comeback in light of the excess of Javascript on this modern web.

The bottom line is: Pick any approach you are already proficient with. But be mindful of the associated downsides, and try to mitigate them before shipping to your users.

With that, here is the boring stack of Sametable:

Front-end

• Webpack, Babel
• Preact

Back-end

• Node — API server with ExpressJS
• Postgresql — Database
• Redis — Store users' session data and cache queries' results.

Hosting

• Google Cloud Platform — GAE for hosting Nodejs, GCE for hosting Redis.
• Firebase — For hosting my SPA.

Repo

https://github.com/kilgarenone/boileroom

This repo contains the structure I'm using to develop my SaaS. I have one folder for the client stuff, and another for the server stuff:

- client
    - src
      - components
      - index.html
      - index.js
    - package.json
    - webpack.config.js
    -.env
    -.env.development
- server
    - server.js
    - package.json
    - .env
- package.json
- .gitignore
- .eslintrc.js
- .prettierrc.js
- .stylelintrc.js

The file structure always aims to be flat, cohesive, and as linear to navigate as possible. Each 'component' is self-contained within a folder with all its constituent files (html|css|js). For example, in a 'Login' route folder:

- client
   - src
     - routes
       - Login
         - Login.js
         - Login.scss
         - Login.redux.js

I learned this from the Angular2 style guide which has a lot of other good stuff you can take away. Highly recommended.

Start Full-stack Development Locally

The package.json at the root has a npm script that I will run to boot up both my client and server to begin my local development:

"scripts": {
    "client": "cd client && npm run dev",
    "server": "cd server && npm run dev",
    "dev": "npm-run-all --parallel server client"
}

Run the following in a terminal at your project's root:

npm run dev

Client

- client
    - src
      - components
      - index.html
      - index.js
    - package.json
    - webpack.config.js
    -.env
    -.env.development

The file structure of the 'client' is quite like that of the 'create-react-app'. The meat of your application code is inside the src folder in which there is a components folder for your functional React components; index.html is your custom template provided to the html-webpack-plugin; index.js is a file as a entry point to Webpack.

Npm Script(Client)

The client's package.json file has two most important npm scripts: 1) dev to start development, 2) build to bundle for production.

"scripts": {
    "dev": "cross-env NODE_ENV=development webpack-dev-server",
    "build": "cross-env NODE_ENV=production node_modules/.bin/webpack"
}

Environment Variables

It's a good practice to have a .env file where you define your sensitive values such as API keys and database credentials:

SQL_PASSWORD=admin
STRIPE_API_KEY=1234567890

A library called dotenv is usually used to load these variables into our application code for consumption. However, in the context of Webpack, we will use dotenv_webpack to do that during compile and build time as shown here. The variables will then be accessible in the process.env object in your codebase:

// payment.jsx

if (process.env.STRIPE_API_KEY) {
  // do stuff
}

Webpack & Babel

Webpack is used to lump all my UI components and its dependencies (npm libraries, files like images, fonts, SVG) into appropriate files like .js, .css, .png files. During the bundling, Webpack will run through my babel config, and, if necessary, transpiles the Javascript I have written to an older version(e.g. es5) to support my targeted browsers.

When Webpack has done its job, it will have generated one (or several) .js and .css files. Then by using a webpack plugin called 'html-webpack-plugin', references to those JS and CSS files are automatically (default behaviour) injected respectively as <script> and <link in your index.html. Then when a user requests your app in a browser, the 'index.html' is fetched and parsed. When it sees <script> and <link>, it will fetch and execute the referenced assets, and finally your app is rendered(i.e. client-side rendering) in all its glories to the user.

If you are new to Webpack/Babel, I'd suggest learning them from their first principles to slowly build up your configuration instead of copy/pasting bits from the web. Nothing wrong with that, but I find it makes more sense doing it once I have the mental models of how things work.

I wrote about the basics here:

• Webpack

Once I understood the basics, I started referring to this resource for more advanced configuration.

• Babel

Web Performance

To put it simply, a web app that performs well is good for your users and business.

Although web perf is a huge subject that's well documented, I would like to talk about few of the most impactful things I do for web perf (apart from optimizing the images which can account for over 50% of a page's weight).

Critical rendering path

The goal of optimizing for the 'critical rendering path' in your page is to have it rendered and be interactive the soonest possible to your users. Let's do that.

We mentioned before that 'html-webpack-plugin' automatically injects references of all Webpack-generated .js and .css files for us in our index.html. But we don't want to do that now to have full control over their placement and applying the resource hints, both of which are a factor in how efficient a browser discovers and downloads them as chronicled in this article.

Now, there are Webpack plugins that seem to help us in this respect, but:

• There was no intuitive way to control the ordering of my <script. Well, there is this method, but how about ordering among my <link> too?
• There was no plugin that preload my CSS the way I wanted as we will see later. Well, there is this (no control over attributes), this (same), and this (no clear support for MiniCssExtractPlugin).

Even if I could've somehow hack them all together, I would have decided against it in a heartbeat if I'd known I could do it in an intuitive and controlled way. And I did.

So go ahead and disable the auto-injection:

// webpack.production.js
plugins: [
  new HtmlWebpackPlugin({
    template: settings.templatePath,
    filename: "index.html",
    inject: false, // we will inject ourselves
    mode: process.env.NODE_ENV,
  }),
];

And knowing that we can grab Webpack-generated assets from the htmlWebpackPlugin.files object inside our index.html:

// example of what you would see if you
// console.log(htmlWebpackPlugin.files)

{
  "publicPath": "/",
  "js": [
    "/js/runtime.a201e1a.js",
    "/vendors~app.d8e8c.js",
    "/app.f8fb511.js",
    "/components.3811eb.js"
  ],
  "css": ["/app.5597.css", "/components.b49d382.css"]
}

We inject our assets in index.html ourselves:

<% if (htmlWebpackPlugin.options.mode === 'production') { %>

<script
  defer
  src="<%= htmlWebpackPlugin.files.js.filter(e => /^\/vendors/.test(e))[0] %>"
></script>
<script
  defer
  src="<%= htmlWebpackPlugin.files.js.filter(e => /^\/app/.test(e))[0] %>"
></script>
<link
  rel="stylesheet"
  href="<%= htmlWebpackPlugin.files.css.filter(e => /app/.test(e))[0] %>"
/>

<% } %>

Note:

• We only do this when building for production; we let webpack-dev-server injects for us during local development.

• We apply the defer attribute on our <script> so that browser will fetch them while parsing our HTML, and only execute the JS once the HTML has been parsed.

  

Inlining CSS and JS

If you managed to separate your critical CSS or you have a tiny JS script, you might want to consider inlining them in <style> and <script>.

'Inlining' means placing corresponding raw content in HTML. This saves network trips, although not being able to cache them is a concern worth factoring in.

Let's inline the runtime.js generated by Webpack as suggested here. Back in the index.html above, add this snippet:

<!-- more <link> and <script> -->

<script>
  <%= compilation.assets[htmlWebpackPlugin.files.js.filter(e => /runtime/.test(e))[0].substr(htmlWebpackPlugin.files.publicPath.length)].source() %>
</script>

The key was the compilation.assets[<ASSET_FILE_NAME>].source():

• compilation: the webpack compilation object. This can be used, for example, to get the contents of processed assets and inline them directly in the page, through compilation.assets[...].source() (see the inline template example). (source)

You can use this method to inline your critical CSS too:

<style>
  <%= compilation.assets[htmlwebpackplugin.files.css.filter(e => /app/.test(e)) [0].substr(htmlWebpackPlugin.files.publicPath.length) ].source() %>
</style>

For non-critical CSS, you can consider 'preload' them.

Preload non-critical CSS

In short:

<link
  rel="stylesheet"
  href="/path/to/my.css"
  media="print"
  onload="this.media='all'"
/>

source

But let's see how to do this with Webpack.

So I have my non-critical CSS contained in a CSS file, which I specify as its own entry point in Webpack:

// webpack.config.js
module.exports = {
  entry: {
    app: "index.js",
    components: path.resolve(__dirname, "../src/css/components.scss"),
  },
};

Finally, I inject it above my critical CSS:

<!-- Preloading non-critical CSS -->
<link
  rel="stylesheet"
  href="<%= htmlWebpackPlugin.files.css.filter(e => /components/.test(e))[0] %>"
  media="print"
  onload="this.media='all'"
/>

<!-- Inlined critical CSS -->
<style>
  <%= compilation.assets[htmlwebpackplugin.files.css.filter(e => /app/.test(e)) [0].substr(htmlWebpackPlugin.files.publicPath.length) ].source() %>
</style>

Let's measure if, after all this, we have actually done anything good. Measuring the Sametable's signup page:

BEFORE

AFTER

Looks like we have improved almost all of the important user-centric metrics (not sure about the First Input Delay..)! ?

Here is a good video tutorial about measuring web performance in the Chrome Dev tool.

Code splitting

Rather than lump all your app's components, routes, and third-party libraries into a single .js file, you should split and load them on-demand based on a user's action at runtime.

This will dramatically reduce the bundle size of your SPA and reduces initial Javascript processing costs. This improves metrics like 'First interactive time' and 'First meaningful paint'.

Code splitting is done with the 'dynamic imports':

// Editor.jsx

// LAZY-LOAD A GIGANTIC THIRD-PARTY LIBRARY
componentDidMount() {
  const { default: MarkdownIt } = await import(
    /* webpackChunkName: "markdown-it" */
    "markdown-it"
  );
  new MarkdownIt({ html: true }).render(/* stuff */);
}

// OR LAZY-LOAD A COMPONENT BASED ON USER ACTION
checkout = () => {
  const { default: CheckoutModal } = await import(
    /* webpackChunkName: "checkoutModal" */
    "../routes/CheckoutModal"
  );
}

Another use case for code splitting is to conditionally load polyfill for a Web API in a browser that doesn't support it. This spares others that do support it from paying the cost of the polyfill.

For example, if IntersectionObserver isn't supported, we will polyfill it with the 'intersection-observer' library:

// InfiniteScroll.jsx

componentDidMount() {
  (window.IntersectionObserver ? Promise.resolve() : import("intersection-observer")).then(() => {
    this.io = new window.IntersectionObserver((entries) => {
      entries.forEach((entry) => {
        // do stuff
      });
    }, { threshold: 0.5 });

    this.io.observe(/* DOM element */);
  });
}

Guide

• https://medium.com/@kilgarenone/pragmatic-code-splitting-with-preact-and-webpack-a3d3b19f86a3

Differential Serving

You have probably configured your Webpack to build your app targeting both modern and legacy browsers like IE11, while serving every user with the same payload. This forces those users who are on modern browsers to pay the cost (parse/compile/execute) of unnecessary polyfills and extraneous transformed codes that are meant to support users on legacy browsers.

'Differential serving' will serve, on one hand, much leaner code to users on modern browsers. And on the other hand, it'll serve properly polyfilled and transformed code to support users on legacy browsers such as IE11.

Although this approach makes for an even more complex build setup and doesn't come without a few caveats, the benefits gained (you can find in the resources below) certainly outweigh the costs. That is unless the majority of your user base is on IE11. In that case, you can probably skip this. But even so, this approach is future-proof as legacy browsers are being phased out.

Repo

https://github.com/kilgarenone/differential-serving

Resources

• https://jasonformat.com/modern-script-loading/#option1loaddynamically — A very good overview of different approaches to differential serving. Sametable is on the 'Option-1'.
• https://github.com/firsttris/html-webpack-multi-build-plugin — This Webpack plugin passes the manifest(i.e. assets' reference) of your modern & legacy scripts to 'html-webpack-plugin' so you can access them in your 'index.html'.
• https://calendar.perfplanet.com/2018/doing-differential-serving-in-2019/ — I learned here about structuring my babel config with its 'babel.config.js' method.
• https://github.com/nystudio107/annotated-webpack-4-config — I learned a lot here about structuring my Webpack configs.

Fonts

Font files can be costly. Take my favorite font Inter for example: If I used 3 of its font styles, the total size could get up to 300KB, exacerbating the FOUT and FOIT situations, particularly in low-end devices.

To meet my font needs in my projects, I usually just go with the 'system fonts' that come with the machines:

body {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
    Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
}

code {
  font-family: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono",
    "Courier New";
}

But if you must use custom web fonts, consider doing it right:

• You should host them yourself.
• 'Font-subsetting' to dramatically reduce the size of the font file.
• Go through this checklist.

Icons

Icons in Sametable are SVG. There are different ways that you can do it:

• Copy and paste the markup of an SVG icon wherever you need it. The downside is it will bloat the HTML and incur parsing costs particularly on mobile.
• Request for your SVG icons over the network:<img src="./tick.svg" />. Unless an SVG is huge (> 5KB), making a request for every one of them seems a bit much.
• Make an icon reusable in the form of a React component. The downside is it unnecessarily introduces Javascript and its associated costs.

Instead, the solution I opted for my icons was 'SVG sprites' which is closer to the nature of SVG itself ( <use> and <symbol>).

Let's see how.

Say there are many places that will use two of our SVG icons. In your index.html:

<body>
  <svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
    <symbol id="pin-it" viewBox="0 0 96 96">
      <title>Give it a title</title>
      <desc>Give it a description for accessibility</desc>
      <path d="M67.7 40.3c-.3 2.7-2" />
    </symbol>
    <symbol id="unpin-it" viewBox="0 0 96 96">
      <title>Un-pin this entity</title>
      <desc>Click to un-pin this entity</desc>
      <path d="M67.7 40.3c-.3 2.7-2" />
    </symbol>
  </svg>
</body>

1. Hide the parent SVG element style="display: none".
2. Give each SVG symbol an unique id <symbol id="unique-id".
3. Make sure to define the viewBox(usually already provided), but skip the width and height.
4. Give it title and desc for accessibility.
5. And of course, the path data of an icon.

And finally, here is how you can use them in your components:

// example.jsx

render() {
  <svg
    xmlns="http://www.w3.org/2000/svg"
    xmlnsXlink="http://www.w3.org/1999/xlink"
    width="24"
    height="24"
  >
    <use xlinkHref="#pin-it" />
  </svg>

}

1. Define the width and height as desired.
2. Specify the id of the <symbol>: <use xlinkHref="#pin-it" />.

Lazy load SVG sprites

Rather than having your SVG symbols in the index.html, you can put them in a .svg file which is loaded only when needed:

<svg xmlns="http://www.w3.org/2000/svg">
  <symbol id="header-1" viewBox="0 0 26 24">
    <title>Header 1</title>
    <desc>Toggle a h1 header</desc>
    <text x="0" y="20" font-weight="600">H1</text>
  </symbol>
  <symbol id="header-2" viewBox="0 0 26 24">
    <title>Header 2</title>
    <desc>Toggle a h2 header</desc>
    <text x="0" y="20" font-weight="600">H2</text>
  </symbol>
</svg>

Put that file in client/src/assets:

- client
  - src
    - assets
      - svg-sprites.svg

Finally, to use one of the symbols in the file:

// Editor.js

import svgSprites from "../../assets/svg-sprites.svg";

/* component stuff */

render() {
  return (
    <button type="button">
      <svg
        xmlns="http://www.w3.org/2000/svg"
        xmlnsXlink="http://www.w3.org/1999/xlink"
        width="24"
        height="24"
      >
        <use xlinkHref={`${svgSprites}#header-1`} />
      </svg>
    </button>
  )
}

And a browser will, during runtime, fetch the .svg file if it hasn't already.

And there you have it! No more plastering those lengthy path data all over the place.

Sources of icons

• https://material.io/resources/icons/?style=baseline
• https://logomakr.com/
• https://github.com/wmira/react-icons-kit#bundled-icon-sets (has a nice list of sources)

References

• https://css-tricks.com/mega-list-svg-information/#svg-icons

Favicon

If I hadn't disabled the inject option of 'html-webpack-plugin', I would have used a plugin called 'favicons-webpack-plugin' that automatically generates all types of favicons (beware - it's a lot!), and injects them in my index.html:

// webpack.config.js

plugins: [
  new HtmlWebpackPlugin(), // 'inject' is true by default
  // must come after html-webpack-plugin
  new FaviconsWebpackPlugin({
    logo: path.resolve(__dirname, "../src/assets/logo.svg"),
    prefix: "icons-[hash]/",
    persistentCache: true,
    inject: true,
    favicons: {
      appName: "Sametable",
      appDescription: "Manage your tasks in spreadsheets",
      developerName: "Kheoh Yee Wei",
      developerURL: "https://kheohyeewei.com", // prevent retrieving from the nearest package.json
      theme_color: "#fcbdaa",
      // specify the vendors that you want favicon for
      icons: {
        coast: false,
        yandex: false,
      },
    },
  }),
];

But since I have disabled the auto-injection, here is how I handle my favicon:

1. Go to https://realfavicongenerator.net/

   • Provide your logo in SVG format.
   • Select the 'Version/Refresh' option to enable cache-busting your favicon asset in your users' browser.
   • Complete the instructions at the end. You can store your favicons in any folder in your project.

2. Use 'copy-webpack-plugin' to copy all your favicon assets generated from Step-1, from the folder where you store them (in my case, src/assets/favicon) to Webpack's output's path (default behaviour), so that they will be accessible from the root (i.e. https://example.com/favicon.ico).

   // webpack.config.js
   const CopyWebpackPlugin = require("copy-webpack-plugin");
   
   plugins: [new CopyWebpackPlugin([{ from: "src/assets/favicon" }])];
   

And that's it!

API Calls

A client needs to communicate with a server to perform 'CRUD' operations - Create, Read, Update, and Delete:

Here is my hopefully easy to understand api.js:

There is almost nothing new to learn to start using this API module if you have used the native fetch before.

Usage

// Home.jsx
import { api } from "../lib/api";

async componentDidMount() {
  try {
    // POST-ing data
    const response = await api(
      '/projects/save/121212121',
      {
        method: 'PUT',
        body: JSON.stringify(dataObject)
      }
    )

    // or GET-ting data
    const { myWorkspaces } = await api('/users/home');

  } catch (err) {
    // handle Promise.reject passed from api.js
  }
}

But if you prefer to use a library to handle your HTTP calls, I'd recommend 'redaxios'. It not only shares an API with the popular axios, but it's much more lightweight.

Test Production Build Locally

I always build my client app locally to test and measure in my browser before I deploy to the cloud.

I have an npm script (npm run test-build) in the package.json of the 'client' folder that will build and serve on a local web server. This way I can play with it in my browser at http://localhost:5000:

"scripts": {
    "test-build": "cross-env NODE_ENV=production TEST_RUN=true node_modules/.bin/webpack && npm run serve",
    "serve": "ws --spa index.html --directory dist --port 5000 --hostname localhost"
  }

The app is served using a tool called 'local-web-server'. It's so far the only one I find works perfectly for a SPA.

Security

Consider adding the CSP security headers.

To add headers in firebase: https://firebase.google.com/docs/hosting/full-config#headers

Sample of CSP headers in your firebase.json:

{
  "source": "**",
  "headers": [
    {
      "key": "Strict-Transport-Security",
      "value": "max-age=63072000; includeSubdomains; preload"
    },
    {
      "key": "Content-Security-Policy",
      "value": "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'"
    },
    { "key": "X-Content-Type-Options", "value": "nosniff" },
    { "key": "X-Frame-Options", "value": "DENY" },
    { "key": "X-XSS-Protection", "value": "1; mode=block" },
    { "key": "Referrer-Policy", "value": "same-origin" }
  ]
}

If you use Stripe, make sure you add their CSP directives too: https://stripe.com/docs/security/guide#content-security-policy

Finally, make sure you get an A here and pat yourself on the back!

Design

Before I start to code anything up, I wanted to have a mental reel of how I would want to on-board a new user to my app. Then I would sketch on a notebook of what it might look like doing it, and re-iterate the sketches while playing and rehashing the reel in my head.

For my very first 'sprint', I would primarily build a 'UI/UX framework' upon which I would add pieces over time. However, it's important to remember that every decision you make during this process should be one that's open-ended and easy to undo.

This way a 'small'— but careful—decision won't spell doom when you get carried away with any over-confident and romantic convictions.

Not sure if that made any sense, but let's explore a few concepts that helped structure my design to be coherent in practise.

Modular Scale

Your design will make more sense to your users when it flows according to a 'modular scale'. That scale should specify a scale of spaces or sizes that each increment with a certain ratio.

One way to create a scale is with CSS 'Custom Properties'(credits to view-source every-layout.dev):

:root {
  --ratio: 1.414;
  --s-3: calc(var(--s0) / var(--ratio) / var(--ratio) / var(--ratio));
  --s-2: calc(var(--s0) / var(--ratio) / var(--ratio));
  --s-1: calc(var(--s0) / var(--ratio));
  --s0: 1rem;
  --s1: calc(var(--s0) * var(--ratio));
  --s2: calc(var(--s0) * var(--ratio) * var(--ratio));
  --s3: calc(var(--s0) * var(--ratio) * var(--ratio) * var(--ratio));
}

If you don't know what scale to use, just pick a scale that fits closest to your design and stick to it.

Then create a bunch of utility classes, each associated with a scale, in a file call spacing.scss. I will use them to space my UI elements across a project:

.mb-1 {
  margin-bottom: var(--s1);
}
.mb-2 {
  margin-bottom: var(--s2);
}
.mr-1 {
  margin-right: var(--s1);
}
.mr--1 {
  margin-right: var(--s-1);
}

Notice that I try to define the spacing only in the right and bottom direction as suggested here.

In my experience, it's better to not bake in any spacing definitions in your UI components:

DON'T

// Button.scss
.btn {
  margin: 10px; // a default spacing; annoying to have in most cases
  font-style: normal;
  border: 0;
  background-color: transparent;
}

// Button.jsx
import s from './Button.scss';

export function Button({children, ...props}) {
  return (
    <button class={s.btn} {...props}>{children}</button>
  )
}

// Usage
<Button />

DO

// Button.scss
.btn {
  font-style: normal;
  border: 0;
  background-color: transparent;
}

// Button.jsx
import s from './Button.scss';

export function Button({children, className, ...props}) {
  return (
    <button class={`${s.btn} ${className}`} {...props}>{children}</button>
  )
}

// Usage
// Pass your spacing utility classes when building your pages
<Button className="mr-1 pb-1">Sign Up</Button>

Colors

There are many color palette tools out there. But the one from Material is the one I always go to for my colors simply because they are laid out in all their glory! ?

Then I will define them as CSS Custom Properties again:

:root {
  --black-100: #0b0c0c;
  --black-80: #424242;
  --black-60: #555759;
  --black-50: #626a6e;

  font-size: 105%;
  color: var(--black-100);
}

CSS Reset

The purpose of a 'CSS reset' is to remove the default styling of common browsers.

There are quite a few of those out there. Beware that some can get quite opinionated and potentially give you more headaches than they're worth. Here is a popular one: https://meyerweb.com/eric/tools/css/reset/reset.css

Here is mine:

*,
*::before,
*::after {
  box-sizing: border-box;
  overflow-wrap: break-word;
  margin: 0;
  padding: 0;
  border: 0 solid;
  font-family: inherit;
  color: inherit;
}

/* Set core body defaults */
body {
  scroll-behavior: smooth;
  text-rendering: optimizeLegibility;
}

/* Make images easier to work with */
img {
  max-width: 100%;
}

/* Inherit fonts for inputs and buttons */
button,
input,
textarea,
select {
  color: inherit;
  font: inherit;
}

You could also consider using postcss-normalize that generates one according to your targeted browsers.

A Styling Practice

I always try to style at the tag-level first before bringing out the big gun if necessary, in my case, 'CSS Modules', for encapsulating styles per component:

- src
  - routes
    - SignIn
      - SignIn.js
      - SignIn.scss

The SignIn.scss contains CSS that pertains only to the <SignIn /> component.

Furthermore, I don't use the CSS libraries popular in the React ecosystem such as 'styled-components' and 'emotion'. I try to use pure HTML and CSS whenever I can, and only let Preact handle the DOM and state updates for me.

For example, for the <input/> element:

// index.scss

label {
  display: block;
  color: var(--black-100);
  font-weight: 600;
}

input {
  width: 100%;
  font-weight: 400;
  font-style: normal;
  border: 2px solid var(--black-100);
  box-shadow: none;
  outline: none;
  appearance: none;
}

input:focus {
  box-shadow: inset 0 0 0 2px;
  outline: 3px solid #fd0;
  outline-offset: 0;
}

Then using it in a JSX file with its vanilla tag:

// SignIn.js

render() {
  return (
    <div class="form-control">
      <label htmlFor="email">
        Email&nbsp;
        <strong>
          <abbr title="This field is required">*</abbr>
        </strong>
      </label>
      <input
        required
        value={this.email}
        type="email"
        id="email"
        name="email"
        placeholder="e.g. sara@widgetco.com"
      />
    </div>
  )
}

Layout

I use CSS Flexbox for layout works in Sametable. I didn't need any CSS frameworks. Learn CSS Flexbox from its first principles to do more with less code. Plus, in many cases, the result will already be responsive thanks to the layout algorithms, saving those @media queries.

Let's see how to build a common layout in Flexbox with a minimal amount of CSS:

See the Pen Sidebar/Content layout on CodePen.

Resources

• Flexbox froggy
• Everything you need to know about flexbox

Server

- server
  - server.js
  - package.json
  - .env

The server is run on NodeJS(ExpressJS framework) to serve all my API endpoints.

// Example endpoint: https://example.com/api/tasks/save/12345
router.put("/save/:taskId", (req, res, next) => {});

The server.js contains the familiar codes to start a Nodejs server.

File Structure

I'm grateful for this digestible guide about project structure, which allowed me to hunker down and quickly build out my API.

Npm Script(Server)

In the package.json inside the 'server' folder, there is a npm script that will start your server for you:

"scripts": {
  "dev": "nodemon -r dotenv/config server.js",
  "start": "node server.js"
}

• The dev script 'preload' dotenv as suggested here. And that's it— You will have access to the env variables defined in the .env file from the process.env object.

• The start script is used to start our Nodejs server in production. In my case, GCP will run this script to bootup my Nodejs.

Database

I use Postgresql as my database. Then I use the 'node-postgres'(a.k.a pg) library to connect my Nodejs to the database. Once that's done, I can do CRUD operations between my API endpoints and the database.

Setup

For local development:

1. Download Postgresql here. Get the latest version. Leave everything as it is. Remember the password you set. Then,

   • Open 'pgAdmin'. It's a browser application.
   • Create a database for you app:

2. Define a set of environment variables in the .env file:

   DB_HOST='localhost'
   DB_USER=postgres
   DB_NAME=<YOUR_CUSTOM_DATABASE_NAME_HERE>
   DB_PASSWORD=<YOUR_MASTER_PASSWORD>
   DB_PORT=5432
   

3. Then we will connect a new client through a connection pool to our Postgresql database from our Nodejs. I do it in server/db/index.js:

   #

   const { Pool } = require("pg");
   
   const pool = new Pool({
     user: process.env.DB_USER,
     host: process.env.DB_HOST,
     port: process.env.DB_PORT,
     database: process.env.DB_NAME,
     password: process.env.DB_PASSWORD,
   });
   
   // TRANSACTION
   // https://github.com/brianc/node-postgres/issues/1252#issuecomment-293899088
   const tx = async (callback, errCallback) => {
     const client = await pool.connect();
     try {
       await client.query("BEGIN");
       await callback(client);
       await client.query("COMMIT");
     } catch (err) {
       console.log(("DB ERROR:", err));
       await client.query("ROLLBACK");
       errCallback && errCallback(err);
     } finally {
       client.release();
     }
   };
   // the pool will emit an error on behalf of any idle clients
   // it contains if a backend error or network partition happens
   pool.on("error", (err) => {
     process.exit(-1);
   });
   
   pool.on("connect", () => {
     console.log("❤️ Connected to the Database ❤️");
   });
   
   module.exports = {
     query: (text, params, callback) => pool.query(text, params, callback),
     tx,
     pool,
   };
   

   • I will use the tx function in an API if I have to call many queries that depend on each other.
   • If I'm making a single query, I will use the query function.

And that's it! Now you have a database to work with for your local development ?

Usage

I will confess: I hand-crafted all the queries for Sametable.

In my opinion, SQL itself is already a declarative language that needs no further abstraction—it's easy to read, understand, and write. It can be maintainable if you separated well your API endpoints.

If you knew you were building a facebook-scale app, perhaps it would be wise to use an ORM. But I'm just a everyday normal guy building a very narrow-scoped SaaS all by myself.

So I needed to avoid overhead and complexity while considering factors such as ease of onboarding, performance, ease of reiteration, and the potential lifespan of the knowledge.

This reminds me of being urged to learn vanilla JavaScript before jumping on the bandwagon of a popular front-end framework. Because you just might realize: That's all you need for what you have set out to accomplish to reach your 1000th customer.

To be fair, though, when I decided to go down this path, I'd had modest experiences in writing MySQL. So if you know nothing about SQL and you are anxious to ship it, then you might want to consider a library like knex.js.

Example

// server/routes/projects.js

const express = require("express");
const asyncHandler = require("express-async-handler");
const db = require("../db");

const router = express.Router();

module.exports = router;

// [POST] api/projects/create
router.post(
  "/create",
  express.json(),
  asyncHandler(async (req, res, next) => {
    const { title, project_id } = req.body;

    db.tx(async (client) => {
      const {
        rows,
      } = await client.query(
        `INSERT INTO tasks (title) VALUES ($1) RETURNING mask_id(task_id) as masked_task_id, task_id`,
        [title]
      );

      res.json({ id: rows[0].masked_task_id });
    }, next);
  })
);

• The express-async-handler is mainly used to handle the async errors in my route handlers. It won't be needed anymore when Express 5 drops.

• Import the db module to use the tx method. Pass your hand-crafted SQL queries and parameters.

That's it!

Creating table schemas

Before you can start querying a database, you need to create tables. Each table contains information about an entity.

But we don't just lump all information about an entity in the same table. We need to organize the information in a way that promotes query performance and data maintainability. And what has helped me in that exercise is a concept called denormalization.

As mentioned, we don't want to store everything about an entity in the same table. For example, say, we have a users table storing fullname, password and email. That's fine so far.

But problem arises when we are also storing the ids of all the projects assigned to a particular user in a separate column in the same table. Instead, I will break them up into separate tables:

1. Create the users table. Notice that it's not storing any data related to 'projects':

   CREATE TABLE users(
     user_id BIGSERIAL PRIMARY KEY,
     fullname TEXT NOT NULL,
     pwd TEXT NOT NULL,
     email TEXT UNIQUE NOT NULL,
   );
   

2. Create a projects table to store data solely about a project's details:

   CREATE TABLE projects(
     project_id BIGSERIAL PRIMARY KEY,
     title TEXT,
     content TEXT,
     due_date TIMESTAMPTZ,
     status SMALLINT,
     created_on TIMESTAMPTZ NOT NULL DEFAULT now()
   );
   

3. Create a 'bridge' table about projects' ownerships by associating the ID of an user with the ID of a project that she owns:

   CREATE TABLE project_ownerships(
     project_id BIGINT REFERENCES projects ON DELETE CASCADE,
     user_id BIGINT REFERENCES users ON DELETE CASCADE,
     PRIMARY KEY (project_id, user_id),
     CONSTRAINT project_user_unique UNIQUE (user_id, project_id)
   );
   

4. Finally, to get all the projects that are assigned to a particular user, we will do what relational database do best: join.

I will put all my schemas in a .sql file at my project's root #:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

CREATE TABLE users(
  user_id BIGSERIAL PRIMARY KEY,
  fullname TEXT NOT NULL,
  pwd TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL,
  created_on TIMESTAMPTZ NOT NULL DEFAULT now()
);

Then, I will copy, paste, and run them in pgAdmin:

No doubt there are more advanced ways of doing this, so it's up to you if you want to explore what you like.

Dropping a database

Deleting an entire database to start with a new set of schemas was something I had to do very often at the beginning.

The trick is: Well, you copy, paste, and run the command below in the database's query editor in pgAdmin:

DROP SCHEMA public CASCADE;
CREATE SCHEMA public;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO public;
COMMENT ON SCHEMA public IS 'standard public schema';

Crafting SQL queries

I write my SQL queries in pgAdmin to get the data I want out of an API endpoint.

To give a sense of direction to doing that in pgAdmin:

Common Table Expressions(CTEs)

I stumbled upon a pattern called CTEs when I was exploring how I was going to get the data I wanted from disparate tables and structure them as I wished, without doing lots of separate database queries and for-loops.

The way CTE works is simple enough, even though it looks daunting: You write your queries. Each query is given an alias name (q, q1, q3). And a next query can access any previous query's results by their alias name (q1.workspace_id):

WITH q AS (SELECT * FROM projects_tasks WHERE task_id=$1)
, q1 AS (SELECT wp.workspace_id, wp.project_id, q.task_id FROM workspaces_projects wp, q WHERE wp.project_id = q.project_id)
, q3 AS (SELECT q1.workspace_id AS workspace_id, wp.name AS workspace_title, mask_id(q1.project_id) AS project_id, p.title AS project_title, mask_id(t.task_id) AS task_id, t.title, t.content, t.due_date, t.priority, t.status)

SELECT * FROM q3;

Almost all the queries in Sametable are written this way.

Redis

Redis is a NoSQL database that stores data in memory. In Sametable, I used Redis for two purposes:

1. Store a user's session data and basic info from the users table—name, email, and a flag that indicates the user is a subscriber or not—once they have logged in.
2. Cache the results of some of my Postgresql's queries to avoid having to query the database if the cache is still fresh.

Installation

I'm on a Windows 10 machine with Windows Subsystem Linux (WSL) installed. This was the only guide I followed to install Redis on my machine:

https://redislabs.com/blog/redis-on-windows-10/

Follow the guide to install WSL if you don't have it already.

Then I will start my local Redis server in WSL bash:

1. Press Win + R.
2. Type bash and enter.
3. In the terminal, run sudo service redis-server start

Now install the redis npm package:

cd server

npm i redis

Make sure to install it in the server's package.json, hence the cd server.

Then I create a file named redis.js under server/db:

// server/db/redis.js

const redis = require("redis");
const { promisify } = require("util");

const redisClient = redis.createClient(
  NODE_ENV === "production"
    ? {
        host: process.env.REDISHOST,
        no_ready_check: true,
        auth_pass: process.env.REDIS_PASSWORD,
      }
    : {}
);

redisClient.on("error", (err) => console.error("ERR:REDIS:", err));

const redisGetAsync = promisify(redisClient.get).bind(redisClient);
const redisSetExAsync = promisify(redisClient.setex).bind(redisClient);
const redisDelAsync = promisify(redisClient.del).bind(redisClient);

// 1 day expiry
const REDIS_EXPIRATION = 7 * 86400; // seconds

module.exports = {
  redisGetAsync,
  redisSetExAsync,
  redisDelAsync,
  REDIS_EXPIRATION,
  redisClient,
};

• By default, node-redis will connect to localhost at port 6379. But that might not be the case in production if you host your Redis in a VM. So I provide this object if it's in production mode:

  {
     host: process.env.REDISHOST,
     no_ready_check: true,
     auth_pass: process.env.REDIS_PASSWORD,
   }
  

  • TBH, I'm not entirely sure about the no_ready_check. I got it from this official tutorial.
  • The auth_pass and host are provided as custom since I host my Redis in a GCE VM where I have set a password on my Redis.

• I promisfy the Redis methods that I will use to make them async to avoid blocking NodeJS's single-thread.

And now you have the Redis for your local development!

Error handling & Logging

Error handling

Error handling in Nodejs has a paradigm which we will explore in 3 different contexts.

To set the stage, we need two things in place first:

1. An npm package called http-errors that will give us a standard error data structure to work with especially in client-side.

   npm install http-errors
   

2. We create a custom error handler at the global level to capture all propagated errors from the routes or the catch blocks via next(err):

   // app.js
   const express = require("express");
   const app = express();
   const createError = require("http-errors");
   
   // our central custom error handler
   // NOTE: DON"T REMOVE THE 'next' even though eslint complains it's not being used!!!
   app.use(function (err, req, res, next) {
     // errors wrapped by http-errors will have 'status' property defined. Otherwise, it's a generic unexpected error
     const error = err.status
       ? err
       : createError(500, "Something went wrong. Notified dev.");
   
     res.status(error.status).json(error);
   });
   

   As you will see, the general pattern of error handling in Nodejs revolves around the 'middleware' chain and the next parameter:

   Calls to next() and next(err) indicate that the current handler is complete and in what state. next(err) will skip all remaining handlers in the chain except for those that are set up to handle errors . . . source

   Note that although this is a common pattern of handling error in Express, you might want to consider an alternative way that's, however, more complicated.

Handle input validation errors

It's a good practise to validate a user's inputs both in the client and server-side.

At the server-side, I use a library called 'express-validator' to do the job. If any input is invalid, I will handle it by responding with an HTTP code and an error message to inform the user about it.

For example, when an email provided by a user is invalid, we will exit early by creating an error object with the 'http-errors' library, and then pass it to the next function:

const { body, validationResult } = require("express-validator");

router.post(
  "/login",
  upload.none(),
  [body("email", "Invalid email format").isEmail()],
  asyncHandler(async (req, res, next) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return next(createError(422, errors.mapped()));
    }

    res.json({});
  })
);

The following response will be sent to the client:

{
  "message": "Unprocessable Entity",
  "email": {
    "value": "hello@mail.com232",
    "msg": "Invalid email format",
    "param": "email",
    "location": "body"
  }
}

Then it's up to you what you want to do with it. For example, you can access the email.msg property to display the error message below the email input field.

Handle errors from business logic

Let's say we have a situation where a user entered an email that didn't exist in the database. In that case, we need to tell the user to try again:

router.post(
  "/login",
  upload.none(),
  asyncHandler(async (req, res, next) => {
    const { email, password } = req.body;

    const { rowCount } = await db.query(
      `SELECT * FROM users WHERE email=($1)`,
      [email]
    );

    if (rowCount === 0) {
      // issue an error with generic message
      return next(
        createError(422, "Please enter a correct email and password")
      );
    }

    res.json({});
  })
);

Remember, any error object passed to 'next'(next(err)) will be captured by the custom error handler that we have set above.

Handle unexpected errors from database

I pass the route handler's next to my db's transaction wrapper function to handle any unexpected erorrs.

router.post(
  "/invite",
  async (req, res, next) => {
    db.tx(async (client) => {
          const {
            rows,
            rowCount,
          } = await client.query(
            `SELECT mask_id(user_id) AS user_id, status FROM users WHERE users.email=$1`,
            [email]
          );
    }, next)
)

Logging

When an error occurs, it's a common practice to 1) Log it to a system for records, and 2) Automatically notify you about it.

There are many tools out there in this area. But I ended up with two of them:

• Sentry for storing details (e.g. stack traces) of my errors, and displaying them on their web-based dashboard.
• pino to enable logging in my Nodejs.

Why Sentry? Well, it was recommended by lots of devs and small startups. It offers 5000 errors you can send per month for free. For perspective, if you are operating a small side project and careful about it, I would say that'd last you until you can afford a more luxurious vendor or plan.

Another option worth exploring is honeybadger.io with more generous free-tier but without a pino transport.

Why Pino- Why not the official SDK provided by Sentry? Because Pino has 'low overhead', whereas, Sentry SDK, although it gives you a more complete picture of an error, seemed to have a complex memory issue that I couldn't see myself being able to circumvent.

With that, here is how the logging system is hooked up in Sametable:

// server/lib/logger.js

// install missing packages
const pino = require("pino");
const { createWriteStream } = require("pino-sentry");
const expressPino = require("express-pino-logger");

const options = { name: "sametable", level: "error" };

// SENTRY_DSN is provided by Sentry. Store it as env var in the .env file.
const stream = createWriteStream({ dsn: process.env.SENTRY_DSN });

const logger = pino(options, stream);
const expressLogger = expressPino({ logger });

module.exports = {
  expressLogger, // use it like app.use(expressLogger) -> req.log.info('haha)
  logger,
};

Rather than attaching the logger(expressLogger) as a middleware at the top of the chain(app.use(expressLogger)), I use the logger object only where I want to log an error.

For example, the custom global error handler uses the logger object:

app.use(function (err, req, res, next) {
  const error = err.status
    ? err
    : createError(500, "Something went wrong. Notified dev.");

  if (isProduction) {
    // LOG THIS ERROR IN MY SENTRY DASHBOARD
    logger.error(error);
  } else {
    console.log("Custom error handler:", error);
  }

  res.status(error.status).json(error);
});

That's it! And don't forget to enable email notification in your Sentry dashboard to get an alert when your Sentry receives an error! ❤️

Permalink for URL Sharing

We have seen URLs consist of cryptic alphanumeric string such as those on Youtube: https://youtube.com/watch?v=upyjlOLBv5o. This URL points to a specific video, which can be shared with someone by sharing the URL. The key component in the URL representing the video is the unique ID at the end: upyjlOLBv5o.

We see this kind of ID in other sites too: vimeo.com/259411563 and subscription's ID in Stripe sub_aH2s332nm04.

As far as I know, there are three ways to achieve this outcome:

1. Generate the ID when inserting data in your database. The generated ID will be the ID in your id column rather than the auto-increment ones:

   | id | title | | ---------- | ------------ | | owmCAx552Q | How to cry | | ZIofD6l3X9 | How to smile |

Then you will expose these IDs in public-facing URLs: https://example.com/task/owmCAx552Q. Given this URL to your backend, you can retrieve the respective resource from the database:

   router.get("/task/:taskId", (req, res, next) => {
     const { taskId } = req.params;
     // SELECT * FROM tasks WHERE id=<taskId>
   });

The downsides to this method that I know of:

• The IDs might be sensitive information to be exposed publicly like that.
• These IDs are detrimental to the performance of indexing and 'joining' on your tables.

2. You keep auto-incrementing your IDs in your tables, but you will represent them by generating their alphanumeric counterpart during database operations:

     SELECT hash_encode(123, 'this is my salt', 10); -- Result: 4xpAYDx0mQ
     SELECT hash_decode('4xpAYDx0mQ', 'this is my salt', 10); -- Result: 123
   

   I had trouble integrating this library on my Windows machine. So I went with the next option.

3. Similar to the second option above but different approach. This will generate numeric ID: https://example.com/task/2013732563294762

User Authentication System

A user authentication system can get very complicated if you need to support things like SSO and third-party OAuth providers. That's why we have third-party tools such as Auth0, Okta, and PassportJS to abstract that out for us. But those tools cost: vendor lock-in, more Javascript payload, and cognitive overhead.

I would argue that if you are starting out and just need some kind of authentication system so you can move on to other parts of your app, and at the same time, overwhelmed by all the dated tutorials that deal with stuff you don't use, well, chances are all you need is the good old way of doing authentication: Session cookie with email and password! And we are not talking about 'JWT' either! None of that.

Guide

Here is a guide I ended up writing. Follow it and you got yourself a user authentication system!

Email

Currently, in Sametable, the only emails it sends are of 'transactional' type like sending a reset password email when users reset their password.

There are two ways to send emails in Nodejs:

1. Roll your own with Nodemailer.

   I wouldn't go down this path because although sending one email might seem a trivial task, doing it 'at scale' is hard; every email must be sent successfully; and they must not end up in a user's spam folder; and other things I'm not aware of.

2. Choose one of the email service providers.

Many email services offer a free-tier plan offering a limited number of emails you can send per month/day for free. When I started exploring this space for Sametable in October 2019, Mailgun stood out to be a no-brainer—It offers 10,000 emails for free per month!

But, sadly, as I was researching for this section write-up, I learned that it no longer offers that. Despite that, though, I would still stick to Mailgun, on their pay-as-you-go plan: 1000 emails sent will cost you 80 cents.

If you would rather not pay a cent for whatever reason, here are two options for you that I could find:

• https://www.mailjet.com/pricing/
• https://www.sendinblue.com/pricing/

But do go down this path while being aware there's no guarantee that these free-tier plans will stay that way forever as was the case with Mailgun.

Implementation

Wrapper file

// server/lib/email.js

// Run 'npm install mailgun-js' in your 'server' folder
const mailgun = require("mailgun-js");

const DOMAIN = "mail.sametable.app";

const mg = mailgun({
  apiKey: process.env.MAILGUN_API_KEY,
  domain: DOMAIN,
});

function send(data) {
  mg.messages().send(data, function (error) {
    if (!error) return;
    console.log("Email send error:", error);
  });
}

module.exports = {
  send,
};

Usage

const mailer = require("../lib/email");

// Simplified for only email-related stuff
router.post(
  "/resetPassword",
  upload.none(),
  (req, res, next) => {
    const { email } = req.body;
    const data = {
      from: "Sametable <feedback@sametable.app>",
      to: email,
      subject: "Reset your password",
      text: `Click this link to reset your password: https://example.com?token=1234`,
    };
    mailer.send(data);
    res.json({});
  })
);

Email templates

Each type of email you send could have its own email template whose content can be varied with dynamic values you can provide.

Tool

mjml is the tool I use to build my email templates. Sure, there are many drag-and-drop email builders out there that don't intimidate with the sight of 'codes'. But if you know just basic React/HTML/CSS, mjml would give you great usability and maximum flexibility.

It's easy to get started. Like the email builders, you compose a template with a bunch of reusable components, and you customize them by providing values to their props.

Here are the places where I would write my templates:

• This VSCode extension
• Live code editor

Example template

Result

Notice the placeholder names that are wrapped in double curly brackets such as {{project_title}}. They will be replaced with their corresponding value by, in my case, Mailgun, before being sent out.

Integration with Mailgun

First, generate HTML from your mjml templates. You are able to do that with the VSCode extension or the web-based editor:

Then create a new template on your Mailgun dashboard:

Send an email with Mailgun in Nodejs

Inside a route:

const data = {
  from: "Sametable <feedback@sametable.app>",
  to: email,
  subject: `Hello`,
  template: "invite_project", // the template's name you gave when you created it in mailgun
  "v:invite_link": inviteLink,
  "v:assigner_name": fullname,
  "v:project_title": title,
};

mailer.send(data);

Notice that, to associate a value with a placeholder name in a template: "v:project_title":'Project Mario'.

How to get one of those hi@example.com

It's an email address people use to contact you about your SaaS, rather than with a lola887@hotmail.com.

There are three options on my radar:

1. If you are on Mailgun, follow this guide. However, the new pay-as-you-go tier has excluded the feature(Inbound Email Routing) that makes this possible. So perhaps the next option;
2. If I ever get kicked out of my '10,000' free-tier in Mailgun, I would give this a shot https://forwardemail.net/en
3. If all else failed, pay for 'Gmail on G Suite'.

Tenancy

When an organization, say, Acme Inc., signs up on your SaaS, it's considered a 'tenant' — They 'occupy' a spot on your service.

While I'd heard of the 'multi-tenancy' term being associated with a SaaS before, I never had the slightest idea about implementing it. I always thought that it'd involve some cryptic computer-sciency maneuvering that I couldn't possibly have figured it all out by myself.

Fortunately, there is an easy way to do 'multi-tenancy':

Single database; all clients share the same tables; each client has a tenant_id; queries the database as per an API request by WHERE tenant_id = $ID.

So don't worry—If you know basic SQL (again indicating the importance of mastering the basics in anything you do!), you should have a clear picture on the steps required to implement this.

Here are three instrumental resources about 'multi-tenancy' I bookmarked before:

• https://stackoverflow.com/a/47783180/73323
• https://stackoverflow.com/a/44530588/73323
• https://blog.checklyhq.com/building-a-multi-tenant-saas-data-model/

Domain name

Sametable.app domain and all its DNS records are hosted in NameCheap. I was on hover before(it still hosts my personal website's domain). But I hit a limitation there when I tried to enter my Mailgun's DKIM value. Namecheap also has more competitive prices in my experience.

At which stage in your SaaS development should you get a domain name? Well, I would say not until when the lack of a DNS registrar is blocking your development. In my case, I deferred it until I had to integrate Mailgun which requires creating a bunch of DNS records in a domain.

How to get one of those app.example.com

You know those URLs that has a app in front of it like app.example.io? Yea, that's a 'custom domain' with the 'app' as its 'subdomain'. And it all started with having a domain name.

So go ahead and get one in Namecheap or whatever. Then, in my case with Firebase, just follow this tutorial and you will be fine.

Deployment

Ugh. This was a stage where I struggled for the longest time ?. It was one hell of a journey where I found myself doubling down on a cloud platform but end up bailing out as I found out their downsides to optimize for developer experience, costs, quota, and performance(latency).

The journey started with me jumping head-first(bad idea) into Digital Ocean since I saw it recommended a lot in the IndieHackers forum. And sure enough, I managed to get my Nodejs up and running in a VM by following closely the tutorials.

Then I found out that the DO Space wasn't exactly AWS S3—It can't host my SPA.

Although I could have hosted it in my droplet and hook up a third-party CDN like CloudFlare to the droplet, it seemed to me unnecessarily convoluted compared to the S3+Cloudfront setup. I was also using a DO's Managed Database(Postgresql) because I didn't want to manage my DB and tweak in the *.config files myself. That costs a fixed \$15/month.

Then I learned about AWS Lightsail which is a mirror image of DO, but to my surprise, with more competitive quota at a given price point:

VM at \$5/month

Managed database at \$15/month

So I started betting on Lightsail instead. But, the \$15/month for a managed database in Lightsail got to me at one point. I didn't want to have to pay that money when I wasn't even sure that I would ever have any paying customers.

At this point, I supposed that I had to get my hands dirty to optimize for the cost factor. So I started looking into wiring AWS EC2, RDS, etc. But there were just too many of AWS-specific things I had to pick up, and the AWS doc wasn't exactly helping either—It's one rabbit hole after another just to do one thing because I just needed something to host my SPA and Nodejs for goodness sake!

Then I checked back in IndieHacker for a sanity check, and came across render.com. It seemed perfect! It's one of those tools that are on a mission 'so you can focus on building your app'. The tutorials were short and got you up and running in no time. And here is the 'but'—It was expensive:

Comparison of Lightsail and Render at their lowest price point

And that's just for hosting my Nodejs!

So what now?! Do I just say f*** it and do whatever it takes to 'ship it'?

But I held my ground. I revisited AWS again. I still believed AWS was the answer because everyone else is singing its song. I must be missing something!

This time I considered their higher-level tools like AWS AppSync and Amplify. But I couldn't overlook the fact that both of them force me to completely work by their standards and library. So at this point, I'd had it with AWS, and turned to another...platform: Google Cloud Platform(GCP).

Sametable's Nodejs, Redis, and Postgresql are hosted on GCP.

The thing that drew me to GCP was its documentation—It's much more linear; code snippets everywhere for your specific language; step-by-step guides about the common things you would do for a web app. Plus, it's serverless! Which means your cost is proportional to your usage.

Deploy Nodejs

The GAE 'standard environment' hosts my Nodejs.

Cost

GAE's standard environment has free quota unlike the 'flexible environment'. Beyond that, you will pay only if somebody is using your SaaS ?.

Guide

This was the only guide I relied on. It was my north star. It covers Nodejs, Postgresql, Redis, file storage, and more:

https://cloud.google.com/appengine/docs/standard/nodejs

Start with the 'Quick Start' tutorial because it will set you up with the gcloud cli which you are going to need when following the rest of the guides, where you will find commands you can run to follow along.

If you aren't comfortable with the CLI environment, the guides will provide alternative steps to achieve the same thing on the GCP dashboard. I love it.

I noticed that while going through the GCP doc, I never had to open more than 4 tabs in my browser. It was the complete opposite with AWS doc—My browser would be packed with it.

Deploy Postgresql

Guide

https://cloud.google.com/sql/docs/postgres/connect-app-engine-standard

Just follow it and you will be fine.

Cost

An instance of Cloud SQL runs a full virtual machine. And once a VM has been provisioned, it won't automatically turn itself off when, for example, it has not seen any usage for 15 minutes. So you will be billed for every hour an instance is running for an entire month unless it'd been manually stopped.

The primary factor that will affect your cost here, particularly in the early days, is the grade of the machine type. The default machine type for a Cloud SQL is a db-n1-standard-1, and the 'cheapest' one you can get is a db-f1-micro:

The other two cost factors are storage and network egress. But they are charged monthly, so they probably won't have as big of an impact on the bill of your nascent SaaS.

If you find the price tags to be too hefty to your liking, keep in mind that they are a managed database. You are paying for all the times and anxiety saved from doing devops on your database. For me, it's worth it.

Setup schemas in production database

Now that I have got a database deployed for production, it's time to dress it up with all my schemas from the .sql file. To do that, I need to connect to the database from pgAdmin:

1. https://cloud.google.com/sql/docs/postgres/external-connection-methods
2. There you will find a table with a list of options for connecting from an external application. I went with the first one: Public IP address with SSL. Follow all the guides in the 'More information' column and you will have all the information needed to create a server in your pgAdmin. You will be fine. If not, email me and I will provide assistance.

Deploy Redis

If you were following the main guide about Nodejs, you can't miss this guide about setting up your Redis in MemoryStore. But I figured it would be more cost-effective to host my Redis in a Google Compute Engine(GCE) which has, unlike MemoryStore, free quota in certain aspects. (See this for comparison of free quota across different cloud platforms)

Guide

1. Setup Redis in a VM.

2) Setup VPC:

Serverless VPC Access enables you to connect from your App Engine app directly to your VPC network, allowing access to Compute Engine VM instances, Memorystore instances, and any other resources with an internal IP address.

3. In your app.yaml file:

   vpc_access_connector:
     name: "<YOURS_HERE>"
   
   env_variables:
     REDIS_PASSWORD: "<PASSWORD_YOU_SET_IN_A_GUIDE_ABOVE>"
     REDISHOST: "<INTERNAL_IP_OF_YOUR_VM>"
     REDISPORT: "6379" # default port when install redis
   

   

4. Finally, in lib/redis.js:

   const redis = require("redis");
   
   const redisClient = redis.createClient(
     NODE_ENV === "production"
       ? {
           host: process.env.REDISHOST,
           port: process.env.REDISPORT, // default to 6379 if wasn't set
           no_ready_check: true,
           auth_pass: process.env.REDIS_PASSWORD,
         }
       : {} // just use the default: localhost and ports
   );
   
   module.exports = {
     redisClient,
   };
   

File Storage

Cloud Storage is what you need for your users to upload their files such as images which they will need to retrieve and possibly display later.

Cost

There is a free tier for Cloud Storage too.

Guide

• You will be fine: https://cloud.google.com/appengine/docs/standard/nodejs/using-cloud-storage

Deploy New Changes in Back-end

I have a npm script in the root's package.json to publish new changes in my back-end to GCP:

"scripts": {
    "deploy-server": "gcloud app deploy ./server/app.yaml"
}

Then run it in a terminal at your project's root:

npm run deploy-server

Hosting Your SPA

When I was still on Lightsail, my SPA was hosted on S3+Cloudfront because I assumed it's better to keep them under the same platform for better latency. Then I found GCP.

As a beat refugee from AWS landing in GCP, I first explored the 'Cloud Storage' to host my SPA, and turns out it wasn't ideal for SPA. It's rather convoluted. So you can skip that.

Then I tried hosting my SPA in Firebase. Easily done in minutes even when it was my first time there. I love it.

Another option you can consider is Netlify which is super easy to get started too.

Deploy New Changes in Front-end

Similarly to deploying back-end changes, I have another npm script in the root's package.json to publish new changes in my front-end to Firebase:

"scripts": {
    "deploy-client": "npm run build-client && firebase deploy",
    "build-client": "npm run test && cd client && npm i && npm run build",
    "test": "npm run lint",
    "lint": "npm run lint:js && npm run lint:css",
    "lint:js": "eslint 'client/src/**/*.js' --fix",
    "lint:css": "stylelint '**/*.{scss,css}' '!client/dist/**/*'"
}

"Whoa hold on, where all that stuff come from??"

They are a chain of scripts that each runs sequentially upon triggered by the deploy-client script. The && character is what glues them together.

Let's hold each other's hands and walk through it from start to finish:

1. First, we do npm run deploy-client,
2. which runs build-client first,
3. which runs test first, (see, we are just following where a script and its && lead us, which is why firebase deploy won't run just yet)
4. which runs lint,
5. which brings us to lint:js first, and next, lint:css,
6. then back to cd client, followed by npm i and npm run build,
7. and finally, it's firebase deploy's turn to run.

Tip: If the changes you made are full-stack, you could have a script that deploys 'client' and 'server' together:

"scripts": {
    "deploy-all": "npm run deploy-server && npm run deploy-client",
}

Rich-text Editor

Building the rich-text editor in Sametable was the second most challenging thing for me. I realized that I could have had it easy with those drop-in editors such as CKEditor and TinyMCE, but I wanted to be able to craft the writing experience in the editor, and nothing can do that better than ProseMirror. Sure, I had other options too, which I decided against for several reasons:

1. Quilljs
   • Seemed many unaddressed issues.
   • Shaped specifically by a special-interest group.
   • Involves hacky workaround once you ventured out from the set of standard use cases.
2. Draftjs
   • They are tightly coupled with React.
   • With the overhead of virtual DOM, they won't perform as well as Prosemirror.
3. trix
   • Based on Web Component. I had issues integrating it in Preact.
   • It wasn't flexible to build a customized editing experience.

Prosemirror is undoubtedly an impeccable library. But learning it was not for the faint of heart as far as I'm concerned.

I failed to build any encompassing mental models of it even after I'd read the guide several times. The only way I could make progress from there was by cross-referencing existing code examples and the manual, and trial-and-error from there. And if I exhausted that too, then I would ask in the forum and it's always answered. I wouldn't bother with StackOverflow unless maybe for the popular Quilljs.

These were the places I went scrounging for code samples:

• The official examples
• Search the forum
• 'Fork' prosemirror-example-setup
• An editor called tiptap that's based on Prosemirror but built for Vuejs. The codebase actually has very few bits of Vuejs. So you can find lots of helpful Prosemirror-specific snippets there(thanks guys!).

In keeping with the spirit of this learning journey, I have extracted the rich-text editor of Sametable in a CodeSandBox:

https://codesandbox.io/s/compassionate-montalcini-gcgwc

?

(Note: Prosemirror is framework-agnostic; the CodeSandBox demo only uses 'create-react-app' for bundling ES6 modules.)

CORS

To stop your browser from complaining about CORS issues, it's all about getting your backend to send those Access-Control-Allow-* headers back per request. (Apologies for oversimplification is in order)

But, correct me if I'm wrong, there's no way to configure CORS in GAE itself. So I had to do it with the cors npm package:

const express = require("express");
const app = express();
const cors = require("cors");

const ALLOWED_ORIGINS = [
  "http://localhost:8008",
  "https://web.sametable.app", // your SPA's domain
];

app.use(
  cors({
    credentials: true, // include Access-Control-Allow-Credentials: true. remember set xhr.withCredentials = true;
    origin(origin, callback) {
      // allow requests with no origin
      // (like mobile apps or curl requests)
      if (!origin) return callback(null, true);
      if (ALLOWED_ORIGINS.indexOf(origin) === -1) {
        const msg =
          "The CORS policy for this site does not " +
          "allow access from the specified Origin.";
        return callback(new Error(msg), false);
      }
      return callback(null, true);
    },
  })
);

Payment & Subscription

A SaaS usually allows users to pay and subscribe to access the paid features you have designated.

To enable that possibility in Sametable, I use Stripe to handle both the payment and subscription flows.

Guide

There are two ways to implement them:

1. Very hands-on that's great for customizing your UI.
2. Checkout. Fastest to implement. This was what I did.

Webhook

The last key component I needed for this piece was a 'webhook' which is basically just a typical endpoint in your Nodejs that can be called by a third-party such as Stripe.

I created a webhook that will be called when a payment has been charged successfully to signify in the user record that corresponds to the payee as a PRO user in Sametable from there onwards:

router.post(
  "/webhook/payment_success",
  bodyParser.raw({ type: "application/json" }),
  asyncHandler(async (req, res, next) => {
    const sig = req.headers["stripe-signature"];

    let event;

    try {
      event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);
    } catch (err) {
      return res.status(400).send(`Webhook Error: ${err.message}`);
    }

    // Handle the checkout.session.completed event
    if (event.type === "checkout.session.completed") {
      // 'session' doc: https://stripe.com/docs/api/checkout/sessions/object
      const session = event.data.object;

      // here you can query your database to, for example,
      // update a particular user/tenant's record

      // Return a res to acknowledge receipt of the event
      res.json({ received: true });
    } else {
      res.status(400);
    }
  })
);

Reference

Here is a code snippet of a webhook: https://stripe.com/docs/webhooks/signatures#verify-official-libraries

Guide

• https://stripe.com/docs/webhooks

Landing page

Building

I use Eleventy to build the landing page of Sametable. I wouldn't recommend Gatsby or Nextjs. They are overkill for this job.

I started with one of the starter projects as I was impatient to get my page off the ground. But I struggled working in them.

Although Eleventy claims to be a simple SSG, there are actually quite a few concepts to grasp if you are new to static site generators(SSG). Coupled with the tools introduced by the starter kits, things can get complex. So I decided to start from zero and take my time reading the doc from start to finish, slowly building up. Quiet and easy.

Guides

• Long version
  • https://tatianamac.com/posts/beginner-eleventy-tutorial-parti/
  • https://www.11ty.dev/docs/
• Short version: https://github.com/kilgarenone/personal-website (the first website I built as my personal site while learning 11ty. It has a homepage and blog posts. Very few concepts introduced here. You could start with this 'starter project')

Hosting

I use Netlify to host the landing page. There are also surge.sh and Vercel. You will be fine here.

Terms and Conditions

T&C makes your SaaS legit. As far as I know, here are your options to come up with them:

1. Write your own https://pinboard.in/tos/.
2. Copy and paste others'. Change accordingly. Never easy in my experience.
3. Lawyer up.
4. Generate them in getterms.io.

Marketing

There is no shortage of marketing posts saying it was a bad idea to "Let the product speaks for itself". Well, not unless you were trying to 'hack growth' to win the game.

The following is the trajectory of existence I have in mind for Sametable:

1. Build something that purportedly solves a problem.
2. Do your SEO. Write the blog posts. Anyone who is affected by the problem that you have solved for will search for it, or know about it by word of mouth.
3. If it still didn't take off, well, chances are you weren't solving a huge real problem, or enough people have already solved it. In that case, just be grateful for whatever success that comes your way over the long haul.

Resources

• https://stripe.com/en-my/atlas/guides/starting-sales
• https://www.coryzue.com/writing/seo-for-developers/

Well-being

It's easy to sit and get lost in our contemporary work. And we do that by accumulating debts from the future. One of the debts is our personal health.

Here is how I try to stay on top of my health debt:

• Install Workrave. You can set it to lock your screen after an interval has passed. Most importantly, it can show some exercises that you can perform behind your computer!
• Get an adjustable standing desk if you can afford it. I got mine from IKEA.
• Do burpees. Stretch those joints. Maintain good posture. Planking helps.
• Meditate to stay sane. I'm using Medito.

??

Thanks for reading. Be sure to check out my own SaaS tool Sametable to manage your work in spreadsheets.

My name is Tigran, I’m 29, and I’m the creator of Cronhub. It’s a side-project, because I’m also a full-time remote engineer at Buffer.

For the past 5 months, I’ve been building Cronhub into a profitable side-business. Cronhub is a cron monitoring tool for developers. It monitors and alerts you if any of your scheduled jobs fail or run longer than expected.

In the past, I’ve shared an article on how I launched Cronhub while working full-time. Today I’m writing about a topic that I had been wondering about for a long time after the launch. Finding the first customers is probably the hardest challenge for every product maker in early stages. This explains why so many people are curious how others managed to find their first customers and read their stories.

In this article, I want to share my story and experience of acquiring my first paid customers after launching my side-project. It’s been a fun and interesting journey full of joy and challenges. I hope I can shed some light on this process and inspire other developers to find their own path by reading my story.

Working on Cronhub

Having a full-time job and trying to build an online business on the side is challenging. The biggest challenge is being very organized with your time and not burning yourself out. Apart from my full-time job at Buffer I usually work on Cronhub 1–2 hours on weekdays and maybe 5–6 hours on the weekends.

I try to get 8-hours sleep each day otherwise I feel tired the next day which really hurts my productivity. Of course, there are some days when I feel down but I know it’s just temporary and I have to wait for the fog to lift. Even though Cronhub is a side-business I pay a lot of attention to prioritize the tasks. I group all my tasks into two high-level buckets.

1. Tasks that will improve the product and make customers happy (product work)
2. Tasks that will bring more visitors by increasing the awareness of the site (marketing work)

There is also the other aspect that improves the activation of the product like creating and activating a Cronhub monitor but I keep it in the product bucket just for the sake of simplicity. The challenge here is finding the sweet spot where you balance the two buckets. Being an engineer I’m naturally more inclined to prioritize more product work but I’m deliberately practicing to overcome this bias.

Current numbers

Currently, I have 7–10 sign-ups daily. Most of the visitors come from my past blog post articles that are not necessarily my target audience. However, content marketing has been the only marketing channel that I’ve used with Cronhub. No cold emails or ads. Here are some metrics that I thought could be interesting to share.

Product Metrics

• Cronhub has around ~1100 signed up users
• 450 active monitors are making around 130,000 pings daily. A monitor is active if it has received at least one ping from an external job or script (e.g. your daily database backup job, weekly digest email job)
• Only in the last 3 weeks, Cronhub reported around 3000 cron job failures to our users. The failure can be either that job failed to run on schedule or ran longer than expected.

Financial Metrics

• Net Revenue since the launch day is $710 (actual total gross revenue minus any fees, refunds, disputes)
• Trial conversion rate 83% (I expect this number will go down eventually)
• Monthly expenses, $57

My expenses haven’t changed since the launch day and I plan to keep it as low as possible. Something I didn’t expect at all is seeing almost half of my customers choosing the yearly billing plan over monthly. I don’t know if I should make some conclusions here. I may if I see this pattern repeats when I gain more customers and data points.

One thing I’m very proud of but still plan to improve is Cronhub’s SEO score. It’s really cool to see a big chunk of my visitors coming from organic search especially for an early product like Cronhub. I think it’s a great validation for me to continue focusing on SEO and improving the organic growth.

Apart from the basic SEO techniques (like keywords, fast page load, etc) and writing content on Cronhub’s blog I haven’t done anything else. I’ll talk more about this a bit later.

Acquiring my first customers

When I launched Cronhub, I could only dream about having 10 customers. Now when I’m here it seems like I’ve so much yet to cover. Getting my first paid customer was crucial for the product. I spent a couple of months building the MVP (minimal viable product) and I wanted to see the returns of my hard work. Also, I think having a product that people pay for is a great way to validate your idea and know that you’re onto something.

I was very lucky to get my first ever customer signing up for the “Developer ($7)” plan the next day after the launch. At that time I only had one paid plan on Cronhub. Getting the Stripe notification of having a new customer was something special. It immediately boosted my confidence and pushed my motivation to the roof.

Later on, this customer switched to the business plan because he and his team needed more monitors. However, when he emailed me the “Business” plan was still in the “Coming soon” phase. I told him that I’d upgrade him within the next couple of days and I did. I made it my top priority. I had him on the business plan the next week.

For the business plan, I had to build team member support from scratch. It was worth it, because I knew I had to support teams on Cronhub anyway. Cronhub is primarily built for developer teams, so team invitation and management support was a no-brainer. It was just a matter of time. I manually upgraded the customer and offered a lifetime discount on the business plan.

I’m always in touch with my first customer. He has been very helpful with providing valuable feedback. My first customer came from the Product Hunt launch. It took me 2 weeks to get two more customers, and both came within the same week.

After the launch, the number of visitors went down, so I had to think about ways to promote Cronhub. I really didn’t think for too long here and decided to do what I enjoy the most: write.

I really love writing. I think of writing as a way of meditating. It helps me to stay focused on one thing which is not always possible with my monkey brain. I knew I could write about my experience of building Cronhub as an online business which I’ve been doing ever since.

Writing helped me to grow my audience as well as market Cronhub. After starting to write I started to grow my Twitter following as well. Below is the graph that illustrates the evolution of my Twitter followers after I started blogging regularly. I think you can see the breaking point!

I started writing regularly in March and you can see how my audience grew ever since

When I decided to make content my primary marketing channel, I started a blog with a new subdomain blog.cronhub.io. With the new blog, my intention was to squeeze out all the SEO benefits. Since I wanted to improve the SEO score to get more organic visitors, I dedicated a week or so to making Cronhub more SEO-optimized.

There are many resources covering the basics which you can find on the web. One example of how my site optimization and content writing helped on the SEO side is this screenshot from Google Analytics. It shows that almost 40% of my traffic on August 23–24 came from organic search. This percentage fluctuates between 20% — 40% every day. I think it’s great, and I have to keep the spirit high. It would be great to know what the industry average is for SaaS products.

The Organic Search was the top acquisition channel for these days

I publish all my articles on Cronhub’s blog first and then I republish them on Medium and Indie Hackers. It’s great that Indie Hackers allows setting a canonical URL for your articles which helps with SEO. One thing I do with my Medium articles is trying to get them published on popular publications such as freeCodeCamp. It’s a great exposure and opportunity to get your voice heard by a large audience. I highly recommend that you give it a try. Here is a quick gif showing my post stats.

My medium states started to grow including the followers count after getting published on FreeCodeCamp

One downside of content marketing is that its very time consuming but it’s a long-term game. It’s like an investment you make now for a better future.

My hunch is that most of my current articles are read by many developers. The question is whether those developers are likely to show interest in cron jobs or not.

As an example, If I had to write an article about Kubernetes Cron Jobs and how they work, I’d expect that most of my readers know at least what cron jobs are. I want to narrow down the scope of my articles and target to more relevant developers. What I care about most is not the number of visitors but the type of visitors. I have a couple of ideas and am excited to see how they perform in the future.

After having three paying customers within the first month, I was very pumped when I got my first yearly “Developer” plan customer in early May. It was around the time when I started to read and learn more about product pricing. I knew nothing about pricing but I was keen to learn.

I talked to product managers and people who understood SaaS pricing model better than I did. (btw I wrote an entire article where I share all my learnings on pricing). Then, I changed my pricing table and added a new intermediate plan called “Startup”. It was in-between “Developer ($7)” and “Business ($49)” plans because I thought the pricing gap between these two plans was too high.

I changed the pricing, and to my big surprise my next customer signed up for the yearly “Startup” plan. It felt really good. I felt like that soccer manager who brings a substitute player to the field and that player scores a goal. Then, I started to slowly acquire new customers until I got to the first sweet spot, 10 paying customers.

However, looking back it did take me almost 5 months until I got my first 10 customers. This is me being a solo founder working around 10–15 hours per week.

It’s been a slow journey and, of course, there are times when you don’t have a single new customer in the span of multiple weeks and you feel terrible with lack of motivation. But I know these things will pass and I’m excited more than ever to get to 100 customers.

If I reflect on my past journey I can certainly say that there is no universal formula that one can use to succeed in this process. However, I believe that patience is the biggest player. You have to believe in yourself and be patient.

If I could make a list of my main learnings, it would look like this;

• Focus on the core product and user experience in the beginning.
• Do not spend too much time thinking about your pricing in your early days. Think of pricing as a feature that you can always iterate on. Start from the MVP.
• Customer support is very important. Be a human, not a company. Be in touch with your customers and ask for feedback.
• Decide what your primary marketing channel is and focus on it in the early days.
• Share all the cool things you’re working on with your audience. People are genuinely interested in them.
• Ask for help and advice. People are generally nice and want you to succeed.

What’s next

My next goal is to go from 10 to 100 customers. Today I asked for advice on Twitter and Joel Gascoigne replied with a great one.

I want to talk more to my customers and adjust my marketing strategy around the value that Cronhub provides to them. Apart from content marketing, I want to create more acquisition channels that have a higher activation rate. Finding a product market fit is my eventual goal. I hope I will get there soon.

As a side note, I’m very excited to share that Cronhub got accepted into YC’s Startup School Advisor track. It’s a 10-week long online course where you get exposed to a mentor and a great community. I’m excited to apply all my learnings on Cronhub and share my experience with you! Stay tuned for a new blog article.

Thanks for reading and let me know in the comments if you have questions for me. I’m happy to share more.

If you’re a developer who is using cron jobs or any scheduled tasks and need monitoring, then I’d love if you could try Cronhub. It will mean a lot to me to know what you think. Thanks.

_I also want to thank my wife Ani for helping me to edit this article. ❤️_

Originally published at blog.cronhub.io on August 27, 2018.

Introduction

If you had asked me a couple months ago if I could ever write an article about pricing, it probably would have made me laugh.

Until a few months agao, I didn’t know anything about product pricing even though I’d launched my first SaaS project. The way I priced my product was by solely relying on my own intuition, as well as looking at how other similar SaaS products priced their services. I think this is what most beginners do.

Then why on earth write an article if I’m not an expert on pricing? Because I’ve come to realize that it’s totally okay to write about topics you’re not expert on.

Chris Coyier’s tweet inspired me to start writing about things I wish I could find on Google.

I started to use blogging as an excuse to learn a specific topic. This article is the fruit of that inspiration, and I’m happy to share it with you all.

There aren’t many articles on the pricing of side-projects, even though the number of revenue-generating side-projects is growing. If you go to Indie Hackers you can see many of them there, and many makers in the community wonder and ask questions about pricing as well.

In this article, I’ve summarized everything I’ve learned about side-project pricing. For the last two months or so, I’ve been reading about pricing and talking to people who are knowledgeable about pricing. It really helped me to understand the basics and create a more successful pricing model for an SaaS project.

I’ve used Cronhub (my side-project) as an example to better explain my view and thinking process, because I believe it’s easier to digest new information using an example.

All my learnings here apply to SaaS products, but I think other types of businesses can benefit from them, too.

Why monetizing?

Monetizing your project from day one is very important. You can think of the “monetization” as a feature that you want your product to have. This feature significantly increases your product’s chances of success. Usually, you build features for your customers but this one is for you, to keep you more motivated to work on your project.

Your motivation and persistence are the key drivers to move your project forward. If you value something, it keeps your motivation high. What’s the easiest way to know whether your project is valuable? Asking people to pay for it. In my opinion, if you can find 10 people willing to pay for your project, you know you’ve got something that people are ready to pay for. After that, you can find the next 100, 1000, and even more. Finding the first customers is the hardest part.

Because finding the first customers is hard, it’s important to set the right pricing model in the beginning. Pricing is a living feature, and as any other feature, it requires multiple iterations until you get it right. It’s totally okay to make mistakes in the beginning. In fact, for Cronhub, I’m still not sure whether I’ve got it right or not. ?

However, I’m open to changing it if that’s what’s best, and that’s what matters.

If your intention is to build a business from your side-project, then you should charge for your project. It’s hard and more often demotivating to work for free. You value your time and others should, too.

Pricing strategies

Since I’m not an expert in this field, I can’t give you very technical answers to pricing strategies. However, one thing I can do is to explain these strategies in a more human way with simple words.

Maybe that’s even better for you? ? Good. Let’s go for it.

The primary goal of a pricing strategy is to maximize your product’s revenue. According to a book that I’ve read, “The anatomy of SaaS pricing strategy” (which a great book btw), there are three pricing strategies for SaaS products.

Cost-Plus Pricing

This is the most basic pricing model you can think of, because it really makes sense. First, you calculate everything that costs money for your project and then add a healthy margin on top of it. The margin is your profit, and it represents the value that you give to your customers.

Let’s take Cronhub as an example. Cronhub is a cron job (or any scheduled task) monitoring tool. Monitors cost me money, because they send emails and SMSs to my users. Sending emails and SMSs is costly for my business. Having more monitors will increase my cost, and that’s why I priced Cronhub by the number of monitors. If you want more monitors, you should pay more.

I think most first-time side-project builders take this approach, because it’s simple and it covers the costs. The challenge with this pricing strategy is the unpredictability of the future. If your costs unexpectedly go up in the future your profit margin will drop and you will have to increase your prices.

Competitor-Based Pricing

As the name implies, this pricing strategy is influenced by your competitors. When you don’t know the initial value of your product, you usually turn to your competitors. You check their pricing tables so you can come up with yours. Well, I’ve done it for Cronhub, too.

If you’re launching a product in a new industry, it makes sense to check competitor pricing because you don’t want to go too high or too low. We’re always afraid of losing customers because of the big price difference from our competitors.

This pricing strategy is simple and less prone to be wrong. You can probably spend an hour or so researching competitors and come up with a pricing table that is similar to your competitors. This way your future customers won’t think that your product is too expensive or too cheap.

The one downside I see for this model is that you don’t want to be guided by your competitors from day one. You want your product to have its own personality, and it should be reflected in the pricing as well. Use competitor pricing as an inspiration and benchmark, but not your guiding strategy. For me, I see this strategy mostly used in combination with other pricing models.

Value-based pricing

This strategy is also called customer-based strategy and is solely based on your customer surveys and research. You want to know how much your customers are willing to pay for your product, and the only way to do so is to go and talk to them. Most companies use in-product surveys to collect this data.

There are many other benefits with this strategy, too. You get to know your customers and their needs, which helps you to build the best product. I think that by following this strategy, you’re most likely to come up with a better pricing table.

However, this model can only be applied after some initial iterations when you have a decent customer base. That’s why I believe that this model should be used as part of the last pricing iterations on your pricing table. It doesn’t mean that you should not talk to your customers from early days. Just set a goal for yourself that you eventually want to use this strategy to decide your pricing table.

You may want to re-apply this strategy often, because your customer base and the market needs keep changing.

Break down your customers into groups

I strongly believe that breaking down your user base into groups is not only important for building a better product, but also for modeling your pricing. When you start thinking about pricing, you naturally measure it with only one dimension using just a single variable (like I used only the monitor count as a pricing measure for Cronhub).

However, you want to add another dimension based on your customer groups. There is a term called “Pricing Axes” which I first heard from Joel Gascoigne in our company retreat this year in Singapore. These axes represent variables that you can use to better model your pricing. For instance, Cronhub has two pricing axes now after launching the team plan: the number of monitors and the team member count.

Breaking down my customers into groups helped me come up with the second axis for Cronhub. I have divided my potential customers into two groups, solo developers, and developer teams. It naturally makes sense that there should be different pricing for each of these groups, because their needs are different. Following this strategy, I’ve created two pricing plans for the team depending on the number of team members they need.

Of course, you can add more axes along the way, and it depends on your product. I think keeping your pricing axes around 2 - 3 makes sense at least in the beginning. Adding more variables may confuse your users, and you don’t want that.

Applying the strategies to Cronhub

I want to also talk about how I’ve applied the above-mentioned pricing strategies for Cronhub and the pricing challenges I’ve faced when starting Cronhub.

Cronhub is a product for developers. I knew that the developer market is not an easy one to be in, but it didn’t stop me starting something I’m very passionate about. I really enjoy hanging out with developers and getting to know them better. For me, what mattered most was to launch a product that would serve this market.

Being a developer, I know how much developers love to use free tools. However, they’re also willing to pay for a product that provides significant value to their flow and productivity. I want Cronhub to be one of these tools. I launched Cronhub with only two plans, “Free” and “Developer ($7/month)”. I wanted to see whether this was something other developers would pay for or not.

My very first pricing model was mostly a symbolic strategy to validate my idea. I didn’t spend much time thinking about the pricing plan and followed Cost-Plus pricing strategy to use the monitor count as a divider between the free and the paid plan. In the first month, I got a couple of paid customers which made me revisit my pricing. That’s when I’ decided to invest a little bit of time to learn about this topic.

After two months of reading and seeking advice from product people, I’ve come up with these key learnings that I’ve applied to Cronhub.

Don’t give up too many things in the free plan

We tend to give up too much in the free plan, especially in the beginning. It’s quite possible that your product doesn’t offer any free plan. But for Cronhub, I wanted to use this channel as a way to acquire customers. Limit the free plan to the minimum.

Know your customer groups

Knowing your customers is important, because it helps you understand how much they can afford to pay for your product. Cronhub’s free and developer plans are intended only for solo developers who have projects on the side.

I now also have two team plans: “Startup $19/month” and “Business $49/month,” and they are intended for engineering teams. Engineering teams should collaborate together, so the team support is necessary. Team sizes are different and that’s why I’ve priced these plans by the number of team members.

Think about your conversion flow

Picturing the customer conversion flow in your head is really helpful in understanding how pricing may work, and that’s why I’ve decided to offer a free plan.

I imagine the flow like this: a developer signs up for the free plan to use it for their personal projects. If they like my product very much, the chances are high that they will also promote my product within their company. It’s the word-of-mouth effect. Now someone from their company signs up to try the team plan, and there you have your potential lead who is very likely to become a customer.

Your pricing is probably too cheap

Don’t be afraid to raise your prices. We tend to undervalue our product, because we are afraid that no one will pay if it’s expensive. This is true especially for people who don’t have experience with pricing.

Unfortunately, pricing your project very cheap may discredit the value your product provides. It can make people question the quality of your product. That’s why you want to find the sweet spot where it’s not cheap and also not expensive.

Pricing will affect your long-term productivity

If you’re a single person team, then you probably do the product support as well. Higher paying customers tend to create fewer support requests compared to the customers who have signed up for the lowest pricing plan.

Think about your time and how you want to spend it. If you’re planning to stay a one-person team, then this will make a huge difference.

For Cronhub, eventually, I’m thinking I’ll only have two plans: a free plan and a business plan. The free plan will be for developers and the business plan for small and medium-sized engineering teams. Instead of having many low paying customers (and spending many hours answering support questions), I would prefer having a small number of high paying customers (and enjoy building a product).

Thank you very much for your time. I hope you’ve enjoyed reading this article and learned a little bit about side-project pricing. Writing is what I enjoy doing most after programming, and I hope to write more articles in the future. If you don’t want to miss any of my writings, follow me on Twitter. Feel free to send me a message or ask questions below!

Finally, If you’re a developer or part of a developer team that uses cron jobs, you can try Cronhub for free to monitor all your cron jobs in a beautiful dashboard.

Originally published at blog.cronhub.io on May 27, 2018.

Today, we are going to see how to create a very simple WordPress plugin for any web app that needs to insert a piece of code to your site.

_Credits: [https://unsplash.com/photos/I8OhOu-wLO4](https://unsplash.com/photos/I8OhOu-wLO4" rel="noopener" target="blank" title=")

To follow this tutorial, you need some knowledge of these basics:

• PHP and OOP
• JavaScript (we’ll use jQuery and Ajax)
• WordPress development (as most functions are from the WordPress core).

You can find a working result of this tutorial on this Github repository.

These web apps could be anything, like CrazyEgg, Freshbook, Google Analytics, Facebook Pixel, or Feedier. Why? They all need to inject some HTML / JavaScript code to your site for various purposes.

This “code” is always parametrized with variables, and is usually a pain for the site owner. This is because you need to edit the theme’s templates. So, how about we create a plugin to do that for us? Okay, let’s do it!

Step 1: Find your web app

The goal of this tutorial is to create a WordPress plugin that adds a WordPress admin page. Plus, we’ll also add some settings to configure the app’s in-site widget and inject the HTML / JS code in our web page automatically. Nothing fancy, just something that works fine.

Please note: we do need a web application for this tutorial. We will use Feedier for this example. However, if you have another web application that you’d like to use in this tutorial, please do. Just rename anything named “feedier” with your app’s name and adapt the settings to what that app needs. Most of them will give you a snippet to add to your site in order to make it work.

Here’s a quick briefing of Feedier if you’ve never heard of it:

• It’s a feedback collector tool, using surveys to understand your users
• It’s very flexible
• It’s free!
• Has a good API (very important here)
• Has an in-site widget (very important here)
• Lets you reward your customers
• Lets you create conditional questions
• Has a complete analytic report dashboard
• Lets you manage feedback individually

Here is the widget we want to add automatically:

Preview of the widget on woffice.io

If you signed up for Feedier, then you can simply find the code in the Share tab of your survey:

_Grab the snippet from [feedier.com](https://feedier.com/?utm_medium=article&utm_source=medium&utm_campaign=medium-wordpress-awareness-2018-05-21&utm_content=how-to-create-a-wordpress-plugin-for-your-web-app" rel="noopener" target="blank" title=")

Step 2: Setup our plugin and its architecture

WordPress plugin are by design very simple. Our plugin will only need two files.

• feedier.php: main plugin’s PHP file.
• assets/js/admin.js: JavaScript script to save the options using Ajax.

You can create a new “feedier” directory (or name of your web app) in your wp-content/plugins/ folder.

The most important file will be the plugin’s feedier.php class. Here is its structure:

We are doing a few things here:

• Declaring our plugin using the header comments
• Defining a few handy constants to be able to find the plugin’s URL and PATH easily
• Declaring our plugin class that will contain everything we need in this plugin. We just need a constructor method for now.

You should already see the plugin in your Plugins page, even though it’s not doing anything yet:

Activate the plugin from WordPress admin panel

Step 3: Create our admin page

For this part, we will add a new Feedier admin page to our WordPress site and dynamically fetch our surveys from Feedier’s API.

In our class’ constructor, let’s register three new actions which are required to add an admin page on WordPress:

• addAdminMenu will add a new page in the WordPress left menu. There will be also a callback to another method containing the page’s content.
• storeAdminData will be called whenever the user clicks the “Save settings” button.
• addAdminScripts will register a new JavaScript file to our WordPress admin in order to save the form’s data. But it also exchanges some variables between the PHP side and JavaScript side.

The first step is very easy. We just register the page, like this:

As you can see, we use WordPress localization functions for all strings. Note that the

array($this, ‘adminLayout’)

is where we call another method containing the page’s content. The form needs to be adapted to your web app.

Here, we first need to get the public and private Feedier API keys. Once saved, we are going to use the private key to dynamically retrieve our surveys. Whenever we get the surveys and not an API error, we display some new options to configure the widget.

At the beginning of this method, you can see that we are first getting the saved data with:

$data = $this->getData();

And getting the surveys from the Feedier API:

$surveys = $this->getSurveys($data[‘private_key’]);

So let’s declare the first one:

This function just reads our plugin’s option and gives us an array back so we can save multiple values in the same option.

To get the second method working, we need the Feedier private key. This depends on the first one to access this key saved in the option:

The Feedier API is documented here, so you can see what you will get in the response.

At this moment, we have a complete new Admin page. But nothing happens when we click on the save button, because there is no saving mechanism — yet.

Good enough, let’s save our data!

As mentioned before, we will save our data using AJAX. Therefore, we need to register a new JavaScript file and exchange data using the wp_localize_script() function:

We also need to add a new file /assets/js/admin.js. That will simply make an Ajax call, and WordPress will automatically route the request correctly to the right method (already done in the constructor). You can read more about how WordPress smartly handles AJAX requests here.

At this very moment, we can click the save button and the above script will make an HTTP POST request to WordPress. We also append an action parameter containing: store_admin_data (which we declared at the beginning at this part in the constructor):

add_action( ‘wp_ajax_store_admin_data’, array( $this, ‘storeAdminData’ ) );

The method storeAdminData will receive the POST request and save the values we need in our WordPress option.

A few notes on the above method:

• We use a “WordPress nonce” to handle the security and make sure this is coming from the website and not a hacker faking the request.
• We identify the fields we need to save using a “feedier_” prefix. Once received, we loop through all the $_POST data and only save those fields. We also remove the prefix before saving every field.

That’s it for the saving process. When we click save, we can see a POST request and our data being saved on the database within the wp_options table.

Perfect, we are done with the admin page.

Step 4: Insert the dynamic code automatically into our pages

Now that we have our options saved, we can create a dynamic widget that will depend on the options set by the user though our admin page. We already know what the web app expects from us.

Something like:

<div class=”feedier-widget” data-type=”engager” data-position=”right” data-carrier-id=”x” data-key=”xxxxxxxxxxxxxxxxx”></div>

<! — Include this line only one time, also if you have multiple widgets on the current page →

<script src=”https://feedier.com/js/widgets/widgets.min.js" type=”text/javascript” async></script>

Thus, the first thing we want to do is to create a new method to our plugin that will print this code depending on the variables set by the user. So, using the architecture we already set up in the last part:

Now, we just need to call this function on every page load to add it at the bottom of the page. To do this, we’ll hook our method to the wp_footer action. By registering a new action into our class’ constructor:

That’s it!

Any questions, feedback, or ideas? Let me know in the comments!

You can find a working version of this tutorial on this Github repository.

2Fwebd/feedier-wordpress-plugin
_Contribute to feedier-wordpress-plugin development by creating an account on GitHub._pxlme.me

Note that this is first version of the plugin, and many things can be improved. I’m open to suggestions and improvements. ?

We are building Feedier. It becomes a no-brainer to collect feedback and build relationships with your customers!

Feedier - Next generation feedback
_Meet Feedier, the next generation customer feedback software that lets you collect valuable feedback. Reward, engage…_feedier.com

Convinced? Sign up for free at feedier.com ?

_[Feedier.com](https://feedier.com/?utm_medium=article&utm_source=medium&utm_campaign=medium-wordpress-awareness-2018-05-21&utm_content=how-to-create-a-wordpress-plugin-for-your-web-app" rel="noopener" target="blank" title="), the next generation feedback application. Start for free now!

Don’t forget to clap our article and subscribe to get more amazing articles if you liked it?. You can also find us on Twitter.

This article was initially published on our blog here.

This article will go into detail on what you need to automate in order for your SaaS company to have a functional subscription billing solution.

One of the problems SaaS companies face when selling subscriptions is connecting their application to a billing process.

Some of the things that are need to be considered are:

• How will cancellations be handled
• Free trials
• Granting access to new customers

The challenge in managing these billing processes is handling these events, such as restricting access to an application when a trial expires or if there no longer has a valid funding source attached to an account.

The SaaS Subscription Lifecycle

The process a customer goes through when doing business with a SaaS company can be broken down into the five events above. Managing these events is the key to integrating a billing system with a SaaS.

Subscribe ?

This is the first stage in the journey a user takes with a subscription. In this step, the customer has just signed up for a subscription which needs to trigger an automated process.

The process generally looks something like this:

1. A customer orders a subscription for your application.
2. The customer is granted access to your application.
3. After the trial period is over (if there is a free trial), the customer is charged on a recurring basis.

From a DevOps perspective, these are considered “Day 1” operations. These are the steps that a service goes through after being requested in order to be considered “provisioned,” such as installation and configurations of software.

Trialing ⏳

In the trialing stage, a customer has subscribed to a service, but is not paying until their trial expires.

Approximately 75% of SaaS companies offer free trials. Although free trials are almost guaranteed to bring you more paying customers, one of the trickier things about offering them is deciding what happens when a trial expires without a customer adding a funding source.

At this stage of the service lifecycle, a company will need to build logic around trials which will, upon expiration, restrict access to an application and alert the customer that they need to pay.

Upgrade ?

Netflix offers different tiers

Many SaaS businesses support multiple tiers of service. If a customer pays a premium, they have access to additional features. This is considered a “Day 2” operation, actions which can be taken after a service has been provisioned which affect the end user.

Generally, it follows the pattern below:

1. A customer submits a request to upgrade their subscription.
2. The customer’s subscription rate will be increased.
3. The customer will be granted access to new features within the application.

While this usually takes the form of strict pricing tiers, sometimes customers pay “per user per month” or have “thresholds” which if passed will trigger higher rates.

Cancellation ❌

Inevitably, there will be cancellations of subscriptions, also called churning. The steps which occur in order to fulfill a cancellation go as follows:

1. A customer requests a cancellation of a SaaS subscription.
2. They will no longer be charged on a recurring basis.
3. Access to the application will terminate at the end of the current billing cycle.

Reaching out to your former customers after they have cancelled will also require some sort of process. It’s recommended that cancellation triggers a process which sends an automated email to the former customer, perhaps with an attempt to recover the customer or a feedback survey to see what reasons they may have had for canceling.

Resubscribe ↪️

When a former customer decides to return after canceling, a company can’t just go through the original process to subscribe them as a new customer — they need to reactivate the previously terminated access so that they retain all their former data. This process can be described in three steps:

1. A customer resubscribes by adding a valid funding source to their account.
2. Access to the customer account and data is reactivated.
3. The customer will be charged on a recurring basis once more.

Some complex scenarios might include limited time discount codes for resubscribers, a free trial, or part of another service as part of a combo deal.

Conclusion

The key to selling software-as-a-service is connecting software to a billing system that can support the lifecycle I just described. Being able to automate this process is a boon to businesses, since manual processes are one of the biggest barriers to scaling.

Trying to manage the challenges of SaaS billing? Let’s Talk.

We solve challenges SaaS companies face when billing customers by providing easy to integrate hooks which can trigger automated processes.

Kubernetes is an awesome technology, and I personally have seen great gains in my ability to scale, deploy, and manage my own SaaS because of it. But, not everyone would immediately benefit from adopting it for a number of reasons:

• Lack of familiarity with container technology
• Application architecture not being conducive to utilizing the benefits of Kubernetes
• Increased amount of effort versus time spent

If you are interested in Kubernetes but aren’t sure about investing the time/resources needed, this article is for you.

What is your experience with containers? ?

In order to understand what Kubernetes can do for you, you first need to know what benefits containers provide. Before spending time on Kubernetes you should first:

Containerize your application

First and foremost, your application must be containerized. This means defining the steps needed to take a base OS image and install your application on it in a file (usually a Dockerfile).

Going through this process as well as defining environment variables needed to configure your application (such as the URL, username, and password of the database your app uses) will be critical to making your container image usable by Kubernetes.

Also make note of any dependencies your application needs to function and learn how to use the containerized versions of those.

Understand how storage works

Containers are designed to hold only the code needed to run an application. Any persistent data needs to be stored elsewhere, as the process of tearing down and spinning up containers (very common when dealing with containers) also destroys any data stored within the file system of that container.

Knowing how container storage is supposed to work and how to handle things like backing up data, moving that data between containers, and accessing the data from outside the container is very valuable when considering Kubernetes.

Kubernetes makes storage management easier with features such as auto-provisioning. This has the ability to have your storage provider (such as AWS EBS) create new volumes on the fly as new containers are created, automatically mounting them.

Understand how networking works

How you implement networking can play a large role in how you use Kubernetes. Knowing how to open specific systems to the public internet and hiding others, such as databases, while maintaining communication between services is important to understand for starters. Some more complicated operations which I’ve needed to learn were how to integrate load balancing as well as giving each customer’s instance a custom hostname (things which Kubernetes makes a lot easier).

Does Kubernetes solve problems you are currently facing? ?

If you are not using containers to deploy your application, you probably shouldn’t be using Kubernetes yet. The problems Kubernetes aims to solve are problems that arise when you try and scale a container-based infrastructure.

Here are a few of the problems I think Kubernetes is great at solving when trying to deal with containers at scale.

Scaling up resources

Kubernetes is basically a cluster of nodes which provide compute resources that can be consumed by container workloads. This clustered architecture allows for a very easy scale-up or scale-down of resources. You just add or a remove nodes from the cluster, and Kubernetes will automatically utilize those resources or reassign workloads on your existing resources.

This solved a major problem I faced, because I went from having a single server I had to keep scaling up (an annoying manual process) to having the ability to scale up or down my infrastructure with a single command using the CLI.

Performing mass updates

Another problem that Kubernetes solves is the ability to update all your containers. Before, I was writing shell scripts which would pick each relevant container and recreate it using a new image tag. The process would take over an hour, and I had no way of validating that the update was successful. With Kubernetes I was able to perform an update with a single command as in the example below:

// Update all the pods of frontend to a new image tag
$ kubectl rolling-update frontend --image=image:v2

Kubernetes also allows you to update any part of Kubernetes (networks, storage, etc.) with commands based on any criteria. This is a huge step up from writing your own scripts to enact changes to your infrastructure.

Self-healing

The last and one of the most important pieces of Kubernetes I’d like to talk about is the ability to self-heal. If Kubernetes detects something wrong with part of its infrastructure, such as a node not responding or a container not passing its health check, it will perform steps to recreate those parts of itself until things start working again.

This is extremely useful because if a piece of the cluster goes down for any reason, the workload will be reassigned and you can even have Kubernetes recreate entire servers to fix the problem.

Will your application architecture need to change??

Sometimes adapting your app to Kubernetes is like fitting a square peg in a round hole

When I migrated to Kubernetes, there weren’t that many changes I had to make because it was originally architected to be a multi-instance platform deployed via containers.

Here are some of the things I’ve learned while moving my own workload to Kubernetes.

Startup time of your app is important

When you create a new deployment, you have to wait for your app to start before it becomes available to the end-user. This becomes a problem if your deployment process involves creating new instances when an end-user presses a button or if you are performing updates on all your customers instances, as that requires a rebuild of the pods.

When moving to Kubernetes you may need to make some changes to your codebase to make the startup process more efficient so the end-user doesn’t have a degraded experience using your product.

Adapting multi-tenant architectures is difficult

A multi-tenant architecture means you have a single instance of your application which manages all your end-users in partitioned tenants, usually with a single database being shared between everyone.

If your application is not built to utilize clustering (multiple servers acting as a single instance) you should not be using Kubernetes yet.

Generally I see two types of architectures when working with Kubernetes:

• Multi-instance with one instance of the app for each customer
• Multi-tenant architecture with clustering capabilities as they can utilize scaling up and down resources

I personally prefer multi-instance because they are much easier to implement compared to a clustered multi-tenant architecture. Also, the work involved in moving from multi-tenant to multi-instance isn’t too bad compared to adding cluster capabilities to a multi-instance architecture.

Moving to a stateless application is a large amount of effort

One of the great features of Kubernetes is the ability to scale up or down the number of pods in a deployment. But, if your application is not clustered or not stateless, this functionality is wasted since extra pods in a deployment wont be configured properly and can’t be utilized.

The process of utilizing statelessness in Kubernetes is often more trouble than it’s worth, since most times you will need to completely rework the way you handle configurations within your application.

Don’t be discouraged if you don’t want to spend the time to make your application stateless or clustered as there are many ways of adapting stateful deployments to use Kubernetes. But those have their own problems which I will not get into in this article.

Should you adopt Kubernetes? ?

After asking yourself these questions, you should have a pretty good idea if Kubernetes will be a good fit for you at this time. Most early stage startups are probably not going to need it, and more mature ones may have a lot of investment in other technologies so it wouldn’t be feasible to switch.

I think the best case for someone moving to Kubernetes is a startup looking to move from having a Minimum Viable cloud infrastructure that is using containers to power production workloads to something more stable. That was my case, and I can say I went from having periodic downtimes due to resource mismanagement and overworked servers to not having to worry at all about my infrastructure thanks to the power of Kubernetes.

Looking to connect Kubernetes to your SaaS? Lets talk - ben@servicebot.io