Forem: Ayobami Adejumo

I audited 12 startup stacks in 90 days. Here is what breaks before 1,000 users every single time.

Ayobami Adejumo — Thu, 09 Apr 2026 23:01:15 +0000

The thing that breaks before 1,000 users is almost never the code.

Not a race condition. Not a memory leak. Not a missing index. Founders assume their app will collapse because of a bug they could have caught in PR review. Engineers assume they'll get paged for a logic error at 2am. Neither is true.

In twelve startup audits, the first failure was always an infrastructure primitive. A limit someone didn't know existed. An environment that didn't exist at all. A default that worked perfectly at 50 users and silently died at 500.

The first thing I check on any stack is the Supabase project plan. If it is on the free tier with more than 20 active users, the connection pool is already at 60% capacity. Most founders have no idea. They only find out when PGRST 104 appears in their logs at 3pm on a Tuesday — right when their biggest customer is running a demo.

That error message means "too many clients already." Not "your query is slow." Not "your code is wrong." Just: you hit a number you didn't know existed. That is what breaks before 1,000 users. Every single time.

Failure pattern 1 — The Supabase free tier connection cliff

You have 47 active users. Your Product Hunt launch is in 4 hours. Everything worked on staging. Then your Sentry dashboard turns red.

remaining connection slots are reserved for non-replication superuser connections

This is not a database crash. It is a configuration limit. Supabase free tier allows 60 direct connections. At 50 concurrent users — each holding a connection open while they browse, type, or leave a tab in the background — the pool is exhausted. Request 61 gets that error. Every user after that sees a 500 response.

Here is why you never saw this coming. Your local development environment had one user: you. Your staging environment had three test accounts. You never simulated 50 concurrent connections because that requires 50 concurrent humans, not 50 automated requests.

I have seen this exact failure at 3pm on a Tuesday. At 11am on a Monday. And once at 8:47am on the morning of a Product Hunt launch. Two hundred people clicked through. The first ten saw the site. The next 190 saw remaining connection slots are reserved — an error message that means nothing to a non-technical user except "this product is broken." The launch slot passed. There is no second first impression.

The fix takes four minutes once you know what it is:

Enable pgBouncer in the Supabase dashboard (Settings → Database → Connection pooler)
Change your connection string from port 5432 to port 6543
Deploy

That is it. The same free tier now handles 200 concurrent connections instead of 60. No code change. No migration. No additional cost.

Failure pattern 2 — No staging environment

Without staging, every code change is tested on real users. Every deploy is a gamble. The developer pushes a change that works on their laptop and breaks in production because of one difference they could not see.

Here is exactly how that happens. It is 6:13pm on a Thursday. A developer pushes a one-line fix for a typo on the pricing page. The fix works locally. They run git push and vercel deploy --prod. The deploy completes in 47 seconds. The typo is fixed.

But the fix introduced a regression on the payment flow. Why? Because the local environment uses a Stripe test key starting with pk_test_. Production uses a live key starting with pk_live_. The developer never tested the payment flow after the change because the change was "just a typo."

At 9:04pm, a user emails: "Your checkout page gives me an error after I enter my card." At 9:12pm, a second user reports the same thing. At 9:23pm, the founder checks Stripe dashboard. Zero successful charges in the last three hours. Three hours of revenue lost. Twelve customers abandoned.

The developer now has to roll back manually. There is no automated rollback process. They run git revert HEAD, wait for the CI pipeline, manually verify the typo is back but the payment flow works, and redeploy. Total time: 47 minutes.

Here is what a correct staging environment looks like:

Same infrastructure as production
Same environment variable structure (different values)
Same database schema — run pg_dump --schema-only production_database > schema.sql weekly
Different data (seeded test accounts, no real emails)

The deployment workflow becomes: git push → deploy to staging (5 minutes) → run smoke tests (90 seconds) → deploy to production. Three hours of setup once. A 90-second automated check before every deploy. I have seen this gap in nine of twelve startup audits. The answer is always the same: "We meant to set up staging. We just haven't gotten to it yet."

Failure pattern 3 — No error monitoring

Here is how a founder discovers a broken feature without error monitoring. A user emails: "Hey, the export button hasn't worked for the last two days. Love the product otherwise." The founder replies: "Thanks for letting us know — we'll look into it immediately."

What the founder does not know: that user is one in twenty who experienced the problem. The other nineteen left quietly. They did not email. They just stopped using the export feature, assumed the product was unreliable, and started looking for alternatives. By the time the founder knows, the feature has been broken for 47 hours. No one is tracking the revenue impact. No one knows when it started.

Now compare that to what Sentry tells you within 60 seconds of the first error occurring:

The exact line of code: src/components/ExportButton.tsx:47
The exact error message: TypeError: Cannot read property 'map' of undefined
The browser and device: Chrome 122 on macOS, 2560x1440
The user's email address (if logged in)
How many times the error has occurred: 14 times, 9 unique users

A senior engineer looking at that alert can reproduce and fix most errors within 20 minutes. The same engineer without Sentry spends hours unable to reproduce an intermittent failure.

Here is the part that founders do not believe until they see it. Sentry takes 25 minutes to install in a Next.js or Node.js application:

npm install @sentry/nextjs
npx @sentry/wizard -i nextjs

The free tier covers 5,000 errors per month — enough for any startup under 10,000 active users. The paid tier starts at $26 per month. There is no technical reason not to have it. I have audited twelve stacks. Eight of them had no error monitoring. The founders all said the same thing: "We rely on users to tell us when something is broken." Users do not tell you. They leave.

Failure pattern 4 — The free tier that sleeps

Heroku Eco dynos and Render free tier web services spin down after 30 minutes of inactivity. No traffic for half an hour? The server goes to sleep. This is not a bug. It is the feature that makes the free tier free.

When a user hits the application after a period of inactivity, the server has to start up before it can respond. This cold start takes between 10 and 30 seconds. During those seconds, the browser shows a blank screen. No loading spinner. No progress bar. Just white. The user assumes the site is broken. Most leave before the server has finished starting.

A founder demos their product to a potential investor. They open their laptop. They navigate to their own URL. They have not visited the site themselves in the last 45 minutes because they have been preparing for this demo. The site takes 22 seconds to load. The investor sees a blank screen for 22 seconds. The founder refreshes. Another 22 seconds. The investor's first impression of the product's reliability is a 22-second blank screen. The signal sent is not about the product. It is about the team.

This is fixable for $7 per month. A Heroku Basic dyno or a Render paid web service does not sleep. The site loads in under one second every single time. The cost of not fixing it is incalculable. That investor meeting does not happen again. That user who saw a blank screen does not come back.

Here is the alternative if you genuinely cannot afford the paid tier. UptimeRobot on a free plan. Configure it to ping the server every 5 minutes: https://yourapp.com/health. The cold start never happens. This is not a production-grade solution. But it costs $0 and takes 4 minutes to set up. I have audited twelve stacks. Four of them were running on free tier dynos with no keep-alive mechanism. Every single founder said the same thing: "I didn't know it went to sleep."

The pattern across all 12 audits

None of these failures were caused by bad engineering. Not one.

The Supabase free tier is the right choice for day one. The missing staging environment was a pragmatic trade-off when the team was two people and zero customers. The Heroku free tier that sleeps was a smart way to keep costs at zero during the three months before launch. These were rational decisions made by competent engineers who were optimizing for the constraints they had at the time.

The problem is that those constraints change. At zero users, a free tier connection pool of 60 is infinite. At 500 users, it is a wall. At zero users, a hardcoded API key in a private repository feels safe. At 500 users, that key has been cloned onto six laptops, three of which are no longer managed by the company. The gap between "the right choice for day one" and "the wrong choice for launch day" is rarely filled because no one is watching.

Here is the specific moment when these gaps become expensive:

The launch: Product Hunt goes live. Two hundred people click through. The database connection pool exhausts at request 61. The next 139 users see a 500 error. The launch slot passes. There is no second first impression.
The investor demo: The founder opens the laptop. The Render free tier has been idle for an hour. Cold start takes 22 seconds. The investor sees a blank screen. The signal sent is not about the product. It is about the team.
The first enterprise prospect: The security questionnaire arrives. Question 17: "Do you store secrets in your source code repositories?" The founder hesitates. The answer is yes. The deal stalls.

A one-day audit run before any of these moments costs £1,500. Here is what happens in that day: trufflehog scan against the repository history (5 minutes), Supabase project plan review, staging environment verification (pg_dump --schema-only comparison), error monitoring check, cold start audit (curl -w "Time: %{time_total}s" https://yourapp.com/health). The output is a two-page document: five specific gaps, the exact command to verify each one, and the fix time measured in minutes.

A launch failure costs more than £1,500. A failed investor demo costs more than £1,500. A stalled enterprise deal costs multiples of £1,500. The audit is not insurance. Insurance pays out after the loss. The audit prevents the loss from happening at all.

The thing that breaks before 1,000 users is almost never the code. The thing that fixes it is almost never more code. It is a one-day audit, a toggle in a dashboard, a port number change, a $7/month dyno, and a secret scanner that runs for five minutes.

Twelve startups. Every single one had at least three of these gaps. Every single one fixed them in less time than they spent reading this post.

If your stack is on this list, I run a one-day audit. Link in bio.

Git Quick Reference | The Comprehensive Guide to Git

Ayobami Adejumo — Tue, 02 May 2023 18:53:33 +0000

Git is a Version Control System. A version control system is a software designed to record changes within one or more files over time.
When developers work on a project, different files are created and changes are made continuously to parts of the code. As the project grows, some of the code results in conflict. Git enables us to roll back, revert or cancel pending changes within one or more files. Git also enables us to compare the changes made to the different versions of a project. Having understood the importance of git, let's dive in

Installation

If you don't have git already installed on your machine, you can download the latest version from the git-scm website https://git-scm.com/downloads according to the version of your operating system - Windows, Mac, or Linux.
if you're running a Windows operating system, download the Windows version and go to the DOWNLOAD folder in file explorer.
Now double-click to install and follow the prompt. once installed, let's proceed to set up.

Configuration

You can confirm if you correctly installed git with the git --version On confirmation, let's proceed to configure our name and email.

git config --global user.name "firstname lastname"
git config --global user.email "firstname@email.com"
#check this 
git config --global --list

Getting Started

To learn the basic git commands by practice, open the terminal of a text editor such as Vscode and practice with the following commands.

git init
Initialize a new git repo in the current working directory. Without this command, most of the commands below won't work.

git clone [https://yourremoterepo...]
This command helps to download a project from a remote repository. git clone copies the entire repository including branches and commit

git status
Displays the state of the working directory. It displays the files which are staged, unstaged or untracked. This command doesn't make any changes or modify any file.

git add filename
Add file from the working directory to the staging area

git add .
recursive add lets you add all untracked files in the working directory to the staging area.

git commit -m "enter your commit message here"
Create a new commit from changes added to the staging area. The commit must have a message!

$ git rm [filename]
Remove the file from the working directory and staging area.

Reviewing Commit History

$ git log
Used to view the history of committed changes within a repository. git log displays the history of everything.

$ git log --oneline --graph --decorate
Display a text-based graphical representation of the commit history. It shows an overview with reference labels and a history graph.

$ git show commit-id
Show commit log with information such as author, date, and diff output

git diff
show changes between the working directory and the staging area. This helps you track and compare the various changes you've made to code.

git diff --staged [file]
Shows any changes between the staging area and the repository.

Revert or Undo Changes

git checkout [filename]
Discard changes in the working directory. This operation is unrecoverable.

git reset commit-id
Revert your repository to a previously known working state.

git revert
Undo changes to a repository's commit history

$ git revert [commit sha]
Create a new commit, reverting changes from the specified commit.
It generates an inversion of changes.

Git branching model

$ git branch -a
List all local branches in a repository. With -a: show all branches (with remote).

$ git branch [branch_name]
Create a new branch, referencing the current HEAD.

$ git checkout [branch_name]
Switch the working directory to the specified branch.

$ git checkout -b [branch_name]
Create a new branch and switch the working directory to the new branch.

$ git merge [branchname]
Join specified [branchname] into your current branch (the one
you are on currently).

$ git branch -d [branchname]
Remove the selected branch, if it is already merged into any other.

$ git reflog
List operations (e.g. checkouts or commits) made on the local repository.

Tagging

$ git tag
List all tags.

$ git tag [tagname]
Create a tag reference named name for the current commit.

$ git tag -d [tagname]
Remove a tag from the local repository

Synchronizing repositories

$ git fetch [remote]
Download changes from the remote, but not update tracking branches.

$ git fetch --prune [remote]
Delete remote Refs that were removed from the remote repository.

$ git pull [remote]
Fetch changes from the remote and merge the current branch with its upstream.

$ git push [--tags] [remote]
Push local changes to the remote. Use --tags to push tags.

Stashing

$ git stash
Put current changes in your working directory into the stash for later use.

$ git stash pop
Apply stored stash content into the working directory, and clear stash.

$ git stash drop
Delete a specific stash from all your previous stashes

Full Guide: How to Build a UI Component Library

Ayobami Adejumo — Sun, 06 Nov 2022 23:10:42 +0000

The trees that are slow bear the best of fruits. We’ve all heard this phrase thousands of times, but can this be said of modern businesses and technologies where products are shipped everyday?

In a constantly evolving world, you can definitely bear good fruits at a slower pace but there’s no guarantee of being the best. Infact, launching too late has been a major business killer.

Therefore, as a developer you should try to eliminate or substitute your less important tasks to focus most on the high-value tasks.

One area where developers spend a lot of time but ideally they shouldn’t (initially) is the styling of their web app.

Writing CSS code from scratch can be a beautiful experience but if you’re an organization or startup hoping to launch products sooner and faster, writing repetitive css code is not the best. This is the reason for the development of design systems and UI components libraries.

However, you need to first evaluate your need so that you can choose between a ready made UI components or building a custom UI library from scratch. Sometimes, a custom component library is an overkill and you’re much better off using ready-made UI components.

if you are an organisation or a startup looking to create a visual identity for your company (think big companies like Netflix, Amazon, Uber) and can do so without straining your budget, go for it.

Where do we start building?

Numerous sectors such as Architecture or Industrial Design have developed smart modular systems for manufacturing extremely complex objects like airplanes, ships, and skyscrapers. That is, these complex objects are made up of multiple building blocks that can be put together to form a bigger entity.

Inspired by this, Atomic Design was proposed by Brad Frost in 2013 as a system that involves breaking down a website or web application into its basic components so that they are reusable throughout the site. Due to new devices with new screen sizes, that are getting released each year, creating pixel-perfect design gets harder if no systems are put in place

Atomic Design, introduces a methodology for creating scalable systems, reusable components as well as design systems. There are five distinct levels in atomic design

Atoms
Molecules
Organism
Templates
Pages

Atoms - represent the smallest entity in UI elements and they can’t be broken down any further examples of an atom include button, input, label.

Molecules - Molecules are groups of atoms bonded together that take on distinct new properties. For instance, a profile molecule is the combination of avatar atom with name and title labels

Organism - Organisms are more complex UI components composed of groups of molecules and/or atoms header organism;

Templates - Templates are pages without real content.

Pages - Pages are instances of templates that demonstrate the final UI looks like and with real data and contents.

Building a Monorepository

We'll start by setting up a monorepository.

A monorepo is a version-controlled code repository that holds many projects with well defined relationships. While these projects may be related, they are often logically independent and run by different teams.

In this case, the monorepo will contain scss package, react, vue and angular packages.

mkdir seraph-design-system
cd seraph-design-system
yarn init -y

proceed to setup your workspace

"private":"true",

You can check the github repository for project dependencies. Proceed to install and configure lerna.

yarn add --dev lerna
yarn lerna --init

add "useWorspaces": "true" and "stream":"true"
By now, your lerna file should look like;

{
  "$schema": "node_modules/lerna/schemas/lerna-schema.json",
  "useWorkspaces": true,
  "version": "0.0.0",
  "stream": true
}

add worskspaces, dev and build script to package.json;

"scripts": {
    "build": "yarn lerna run build",
    "dev": "yarn lerna run dev"
  },
  "workspaces": {
    "packages": [
      "packages/**",
      "playground/**"
    ]
  },
  "devDependencies": {
    "lerna": "^6.0.1",
    "process": "^0.11.10"
  }

let's create a package structure

Setup Your Package structure in the root

in the root directory - seraph-design-system

mkdir packages
cd packages

create a directory for react, vue, and scss. You can include angular too.

- node_modules/
- packages/
  - react
  - scss
  - vue
- package.json
- lerna.json
- .gitignore

let's create our css architecture.

SCSS Package

To keep the css architecture modular, it’s important to break the code into smaller parts.

Multiple files make the code easier to read, navigate and track. To do that, a CSS preprocessor – such as Sass, LESS or Stylus – or a post-processor – such as PostCSS – is the way to go.

Preprocessors enhance the capabilities of CSS authoring, introducing new features such as variables, mixins and much more. To work with separate files, your code will be divided into partials and imported on a main.scss file, that will compile everything into a single .css file.

3 benefit of using a preprocessor

breaking the code into smaller chunks and separating them by scope;
coding components in a independent and encapsulated manner;
naming CSS selectors according to their purpose and relationship with each other.

Each component should be encapsulated on its own file. For consistency reasons, it’s a good practice to use the same name for the file and main selector

cd packages/scss
mkdir src

Now create a file global.scss in src
in addition to the file, create four folders in src - atoms, molecules, foundation, organisms;

cd into the foundation folder and create your _variables.scss, _typography, _mixins.scss, _all.scss, _colors.scss.

By now, your folder structure should be like:

  - scss
    - src/
        global.scss
        - atoms/
        - foundation/
            _all.scss
            _color.scss
            _mixins.scss
            _typography.scss
            _variables.scss

        - molecules/
        -organisms/

As the names of the files suggest, create all variables as specified in your design (figma) into the _variables.scss.

Proceed to create default colors and typography in their respective files. _mixins.scss should contain reuable styles such as breakpoint sizes.

You can checkout the github repository for more information on this file

import the four files (_variables.scss, _color.scss, _mixins.scss, _typography.scss) into the _all.scss

Then, import the _all.scss into the global.scss (in src) to make it available to gulp-sass for compilation.

Install devDepencies for Scss package

cd package/scss
yarn init -y

yarn add --dev normalize-scss gulp gulp-sass stylelint prettier stylelint-config-sass-guidelines  stylelint-config-prettier stylelint-prettier

let configure normalize-scss and other devDependencies

cd scss/src
mkdir normalize

create two files in the normalize _root.scss and _reset.scss

The _reset.scss contains import from normalize-scss

@import "node_modules/normalize-scss/sass/normalize/import-now";

The _root.scss contains scss root such as

:root{
  ...
}

import these two files (_root.scss and _reset.scss) into the global.scss

- node_modules/
- packages/
  - scss
    - lib/
    - node_modules/
    - src/
        global.scss
        - atoms/
            Button.scss
            Text.scss
            Input.scss
        - foundation/
            _all.scss
            _color.scss
            _mixins.scss
            _typography.scss
            _variables.scss
        - molecules/
            inputfield.scss
    - package.json
    - .stylelintrc.json
    - gulpfile.js

create a .styleintrc.json file and gulpfile.js file.

now run gulp watch.
you should have your compiled files in the dist folder;
congrats.

React UI library Component

cd packages/react
yarn init -y
yarn add --dev react typescript @types/react rollup

since we're building a library, rollup is our preferred bundler.
Therefore, create a tsconfig.json and rollup.config.js file

now make atomic folders like we did for the scss package.

- node_modules/
- packages/
  - react
    - lib/
    - node_modules/
    - src/
        - atoms/
        - molecules/
        - organisms/
    - package.json
    - rollup.config.js
    - tsconfig.json

set up dev and build script

"scripts": {
    "build": "rollup -c",
    "dev": "yarn build --watch"
  }

creating our First Component;

create a Heading components.

cd src/atoms
mkdir Button
cd Button

create two files Heading.tsx and index.ts

atoms/Heading/Heading.tsx

import React from 'react';

interface HeadingProps {
    title: string
    color?: string
}

const Heading: React.FunctionComponent<HeadingProps>({title, color}) => {
    return <h1 style={{color: color}} class='header'>{title}</h1>
}

in the atoms/Heading/index.ts

export {default} from './Heading'

in the src/index.ts

import Heading from './atoms/Heading';
export {
    Heading;
}

Your react package structure looks like

- node_modules/
- packages/
  - react
    - lib/
    - node_modules/
    - src/
        - index.ts
        - atoms/
            - Heading/
                - Heading.ts
                - index.ts
        - molecules
        -organisms
    - package.json
    - rollup.config.js
    - tsconfig.json

now run yarn build to build your component.