Keel
Overview
Founding designer at a pre-seed CI/CD startup. I joined with no brand, no product, and a flow decision I'd later have to reverse, and learned to defend my thinking before shipping it.
Services
Product Design
Product Design
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, and they cost time and money. Monk CI builds fast runners and a dashboard for the teams using them: developers watch which checks failed and why, managers watch speed and cost.
I had never worked in this domain. Before I designed a screen, I had to learn what a run is, what failure looks like, and how developers live inside GitHub. I read docs, watched competitor walkthroughs, and worked through the system with the founder until I understood it well enough to design for it. And well 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, and they cost time and money. Monk CI builds fast runners and a dashboard for the teams using them: developers watch which checks failed and why, managers watch speed and cost.
I had never worked in this domain. Before I designed a screen, I had to learn what a run is, what failure looks like, and how developers live inside GitHub. I read docs, watched competitor walkthroughs, and worked through the system with the founder until I understood it well enough to design for it. And well 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, and they cost time and money. Monk CI builds fast runners and a dashboard for the teams using them: developers watch which checks failed and why, managers watch speed and cost.
I had never worked in this domain. Before I designed a screen, I had to learn what a run is, what failure looks like, and how developers live inside GitHub. I read docs, watched competitor walkthroughs, and worked through the system with the founder until I understood it well enough to design for it. And well 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 until you connected the thing it should have been built on. I was right, but couldn't yet make the reason legible, so it shipped that way and we reversed it weeks later. A decision is only as good as your ability to defend it.
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 until you connected the thing it should have been built on. I was right, but couldn't yet make the reason legible, so it shipped that way and we reversed it weeks later. A decision is only as good as your ability to defend it.
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 until you connected the thing it should have been built on. I was right, but couldn't yet make the reason legible, so it shipped that way and we reversed it weeks later. A decision is only as good as your ability to defend it.
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 a site for an investor meeting 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 planned Lottie animations for the feature sections; free-plan limits forced a fallback to SVG. The site shipped on time. The launch video was built in After Effects but never released, because the launch kept slipping.
The founder needed a site for an investor meeting 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 planned Lottie animations for the feature sections; free-plan limits forced a fallback to SVG. The site shipped on time. The launch video was built in After Effects but never released, because the launch kept slipping.
The founder needed a site for an investor meeting 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 planned Lottie animations for the feature sections; free-plan limits forced a fallback to SVG. The site shipped on time. The launch video was built in After Effects but never released, because the 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 answer three questions: where am I, what is this page for, what do I do first. Three decisions show how I defended the rest.
Developers live in Run History and Cache. Managers live in Analytics and Billing. Every screen had to answer three questions: where am I, what is this page for, what do I do first. Three decisions show how I defended the rest.
Defended by page-job
Analytics started as five charts at equal weight showing current numbers. I rebuilt it around one question: is this failing more than usual? Run History has no concept of normal. Analytics is entirely about deviation from it. Failure rate became the hero, total time moved to Billing, and every chart earned its place against that single job.
Analytics started as five charts at equal weight showing current numbers. I rebuilt it around one question: is this failing more than usual? Run History has no concept of normal. Analytics is entirely about deviation from it. Failure rate became the hero, total time moved to Billing, and every chart earned its place against that single 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. The same check killed a left-border status accent on Run History, no CI tool in the set uses it.
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. The same check killed a left-border status accent on Run History, no CI tool in the set uses it.
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.