← Back

Monk CI

Overview

Founding designer at a pre-seed CI/CD startup. I joined with no brand and no product, made a flow decision that got reversed, and learned the hard way that being right isn't the same as being convincing.

Services

Product Design

Product Design

Branding and Motion

Branding and Motion

Year

2026

What Monk CI is, and what I had to learn

What Monk CI is, and what I had to learn

When engineers push code, automated checks run to confirm nothing broke. Those checks run on machines called runners, which cost time and money. Monk CI builds fast runners and a dashboard for the teams using them developers watch what failed and why, managers watch speed and cost.


I'd never worked in this domain before. Before I touched a screen I had to figure out what a run actually is, what failure looks like from a developer's side, and how people live inside GitHub day to day. Docs, competitor walkthroughs, sitting with the founder until it clicked. It got me far enough to catch a problem the team had missed.

The decision that taught me the rest

The decision that taught me the rest

The first flow connected your GitHub account, had you create a project, then connect your org from inside it. I argued the org was in the wrong place, repos, permissions, and runner options all come from the org, so putting it last meant building an empty project around the one thing it depended on. I was right. I just couldn't make the case well enough at the time, so it shipped anyway and we reversed it a few weeks later.

The first flow connected your GitHub account, had you create a project, then connect your org from inside it. I argued the org was in the wrong place, repos, permissions, and runner options all come from the org, so putting it last meant building an empty project around the one thing it depended on. I was right. I just couldn't make the case well enough at the time, so it shipped anyway and we reversed it a few weeks later.

The first flow connected your GitHub account, had you create a project, then connect your org from inside it. I argued the org was in the wrong place, repos, permissions, and runner options all come from the org, so putting it last meant building an empty project around the one thing it depended on. I was right. I just couldn't make the case well enough at the time, so it shipped anyway and we reversed it a few weeks later.

Why the org had to come first

Why the org had to come first

The org is Monk CI's source of truth. Repos sync from it, permissions inherit from it, runner options unlock from it. A project connected to nothing is a project that can do nothing, which is exactly what the old order produced. Connect the org first, and the project inherits everything the moment it exists.

The org is Monk CI's source of truth. Repos sync from it, permissions inherit from it, runner options unlock from it. A project connected to nothing is a project that can do nothing, which is exactly what the old order produced. Connect the org first, and the project inherits everything the moment it exists.

The org is Monk CI's source of truth. Repos sync from it, permissions inherit from it, runner options unlock from it. A project connected to nothing is a project that can do nothing, which is exactly what the old order produced. Connect the org first, and the project inherits everything the moment it exists.

Brand, before the product existed

Brand, before the product existed

The founder needed something to show investors within days, so I started with the brand, logo, color, type. Instrument Sans for display, Geist for body and interface, a green built to feel fast without being cold. I'd planned Lottie animations for the feature sections, but free-plan limits killed that and I fell back to SVG. Site shipped on time. The launch video got built in After Effects and then just sat there, because launch kept slipping.

A dashboard for two people who want different things

A dashboard for two people who want different things

Developers live in Run History and Cache. Managers live in Analytics and Billing. Every screen had to earn its place against three questions: where am I, what is this page for, what do I do first. Three decisions show how that played out.

Developers live in Run History and Cache. Managers live in Analytics and Billing. Every screen had to earn its place against three questions: where am I, what is this page for, what do I do first. Three decisions show how that played out.

  • Defended by page-job

Analytics started as five charts, all equal weight, all just showing current numbers. I rebuilt it around one question: is this failing more than usual? Run History doesn't have a concept of normal. Analytics is entirely about deviation from it. Failure rate became the hero, total time moved to Billing, and everything else had to justify itself against that one job.

Analytics started as five charts, all equal weight, all just showing current numbers. I rebuilt it around one question: is this failing more than usual? Run History doesn't have a concept of normal. Analytics is entirely about deviation from it. Failure rate became the hero, total time moved to Billing, and everything else had to justify itself against that one job.

  • Defended by reference

I confirmed which fields a cache entry should show by checking GitHub Actions docs, Blacksmith, and Depot, and cut the ones no user makes a decision from. Version was the clearest cut: an internal integrity hash that lives in the database, not in anyone's mental model.

I confirmed which fields a cache entry should show by checking GitHub Actions docs, Blacksmith, and Depot, and cut the ones no user makes a decision from. Version was the clearest cut: an internal integrity hash that lives in the database, not in anyone's mental model.

  • Defended by arithmetic

8vCPU runners are 40% of minutes but 57% of spend, because they cost double per minute. That inversion is why the cost story lives in Billing, not Analytics: it is the only place in the product where minutes resolve into money. Every figure reconciles, repo and runner spend both sum to $3,628.

8vCPU runners are 40% of minutes but 57% of spend, because they cost double per minute. That inversion is why the cost story lives in Billing, not Analytics: it is the only place in the product where minutes resolve into money. Every figure reconciles, repo and runner spend both sum to $3,628.

What I would do differently

What I would do differently

A defensible decision is one whose reasoning is portable: a constraint, a reference, or arithmetic. The defense stays the same. What changes is the decision itself. The onboarding flow would have survived if I had defended it that way the first time. That is the habit I left with.

A defensible decision is one whose reasoning is portable: a constraint, a reference, or arithmetic. The defense stays the same. What changes is the decision itself. The onboarding flow would have survived if I had defended it that way the first time. That is the habit I left with.

Also built

Also built

Pitch deck, sales deck, LinkedIn outreach automation, and the docs infrastructure. I introduced Fumadocs and prototyped the base the team adopted.

Pitch deck, sales deck, LinkedIn outreach automation, and the docs infrastructure. I introduced Fumadocs and prototyped the base the team adopted.

Got a hard problem? Let's figure it out together.

or reach out to me at

Copy component

Copied

madebyhx@gmail.com

Harshit Singh

© 2026 Harshit.

Got a hard problem? Let's figure it out together.

or reach out to me at

Copy component

Copied

madebyhx@gmail.com

Harshit Singh

© 2026 Harshit.

Got a hard problem? Let’s figure it out together.

or reach out to me at

Copy component

Copied

madebyhx@gmail.com

Harshit Singh

© 2026 Harshit.

Create a free website with Framer, the website builder loved by startups, designers and agencies.