Monk CI
TL;DR
Monk CI is a CI/CD platform that runs automated checks on every commit and shows teams what passed, what failed, and what it cost. I joined as founding designer 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 is Monk CI, and what did I have 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.
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 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
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
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.
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.
How do you design one dashboard for two audiences?
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 would I 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.