Building the Room You're Standing In

01 Overview

You're standing in it. This is the case study about the site you're reading.

IMCO is Chris's studio, a representation of what he does as a designer and a developer. The site is its digital footprint: a platform for over a decade in the industry, built for CEOs and business owners who need a website, an app, or an automation set up.

01.1 The problem

Three versions that never shipped, and case studies that took weeks to write.

One row per layer: what kept the portfolio from existing, what it cost, and what we did about it.

What was going wrong	What we did about it
Design problem Three earlier portfolios, none of them finished: we were too busy, and didn't feel the need. Pinning down one design language for this one took months of experimenting. 3 unfinished versions before this one, the fourth.	A blueprint design language first: grid lines, dotted lines, and the palette IMCO has used since version one, settled before the case studies.	See the work
Engineering problem Case studies were written as Markdown files, and each one meant working out at the same time how it fit a template flexible enough for every case study. Two jobs at once writing each case study while shaping the template it had to fit.	One structure every case study follows, kept as records the site reads, and a site built from components that renders them.	See the work
Automation problem Every case study had to be thought out of thin air: what it should say, what to highlight, what to leave out. Up to 2 weeks per case study, before the first word reached the page.	An interview in rounds, each built from the last, and a pipeline that turns the answers into the page.	See the work

What was going wrong

What we did about it

Design problem

Three earlier portfolios, none of them finished: we were too busy, and didn't feel the need. Pinning down one design language for this one took months of experimenting.

3 unfinished versions before this one, the fourth.

A blueprint design language first: grid lines, dotted lines, and the palette IMCO has used since version one, settled before the case studies.

See the work

Engineering problem

Case studies were written as Markdown files, and each one meant working out at the same time how it fit a template flexible enough for every case study.

Two jobs at once writing each case study while shaping the template it had to fit.

One structure every case study follows, kept as records the site reads, and a site built from components that renders them.

See the work

Automation problem

Every case study had to be thought out of thin air: what it should say, what to highlight, what to leave out.

Up to 2 weeks per case study, before the first word reached the page.

An interview in rounds, each built from the last, and a pipeline that turns the answers into the page.

See the work

01.2 The timeline

Started in May 2026, rebuilt around interviews in October, and launching in December.

Four months on the design language, then the case studies, interview first.

2026
May
The work on this version starts, with the design language.
August
The last of four months on the design language, built to be reused.
September
Jake sets up the contact page.
October
Chris designs the interview workflow, and the case studies start coming from it.
December
Launch, planned for the first week.

01.3 Context

A fourth attempt, by a studio that had never needed a portfolio.

What the work started from: why now, why the earlier ones died, and who the site is for.

Version four
We tried three times before. Each one stalled: "we're just too busy and we didn't feel the need."
Word of mouth
For eight years, work came by referral and word of mouth, and nothing had to be shown up front.
Why now
To explore and expand, and because after years of trying, "this might be as good time as any to actually make something for myself."
Who it's for
CEOs and business owners, the people who call the shots. Hire us, and connect us with whoever makes the final decision, not someone who has to convince someone else again.

02 Design solution

Automation drawn as a blueprint, in a palette IMCO has used since version one.

The site had to blend UI/UX design and automation, and Chris pictured automation as grid lines, dotted lines, something that shows a blueprint. The palette he brought into it is his original one, which is why the diagrams look the way they do.

02.1 The work

Every screen of the site, shown whole.

The designs in one long run that pans as you scroll, from Figma and Claude Design. The sections after it are how they were made and the calls that shaped them.

02.2 The design process

From Figma to Claude Design and back, until it was right.

The palette lives in Figma, the designs were worked out in Claude Design against it, and each one went back to Figma once it was settled. One person on the design, so no one else checked it along the way.

The palette, in Figma
Designed in Claude Design
Back to Figma, settled
Built as components

02.3 Design decision

The first try was isometric, and the easy picture was a screenshot. It got a blueprint, and diagrams.

Two calls the design turned on: the language itself, and how the work is shown.

The call	The easy answer	What we chose	What it cost, and what it bought
The design language	The isometric approach, tried first.	Grid lines, dotted lines, and the original palette, as a blueprint.	Months of experimenting, May to August, before it was pinned down. One language that carries design and automation together.
How the work is shown	Screenshots, still images of the screens.	Diagrams that show the flow, built in the site's own Astro, SCSS and GSAP.	Every diagram is built, not exported. The process on the page, including what goes back into what.

The call

The easy answer

What we chose

What it cost, and what it bought

The design language

The isometric approach, tried first.

Grid lines, dotted lines, and the original palette, as a blueprint.

Months of experimenting, May to August, before it was pinned down.

One language that carries design and automation together.

How the work is shown

Screenshots, still images of the screens.

Diagrams that show the flow, built in the site's own Astro, SCSS and GSAP.

Every diagram is built, not exported.

The process on the page, including what goes back into what.

03 Engineering solution

One part, really. Every page is components, and every component starts in the design.

A component in the design is a component on the site, and any page breaks down into them. Astro was the call for it: components that work like the frameworks Chris knows, care for SEO with a blog coming, and page speed as a top priority.

03.1 The wiring

From the design to a live page, and from the contact form back to Chris.

The site from above: the design becomes components, the template fills them from the records, and a push puts it live. The contact page runs on its own wiring, set up by Jake.

The designFigma, Claude Design

ComponentsAstro, SCSS

The pageReads the records

LiveGitHub to Hostinger

The messageResend, kept in Supabase

Chris is notifiedThrough Resend

03.2 The parts

The parts, and where each one runs.

What went in, named as a visitor meets it, and where each one runs.

The part	What it does	Where it runs
Components	The pages, broken down into the same units as the design.	Astro and SCSS, everywhere on the site.
Diagrams	The work drawn as flow, built in code rather than exported.	Astro, SCSS and GSAP, on the page.
Case-study template	Reads each case study's data and renders it in one structure.	At build, from the exported records.
Contact page	Resend receives the message; Supabase keeps it and sends Chris a notification through Resend. Set up by Jake.	Supabase and Resend, over Supabase's custom SMTP.
Deploys	A change pushed to GitHub goes live on its own.	Hostinger.

03.3 How it fits together

The design names the components, the records hold the words, and the template puts them together.

Every component in the design has one on the site. Case studies aren't pages written by hand: they're records in one structure, exported as data the template reads. A push to GitHub and the host picks it up.

03.4 Engineering decision

The easy build was a case study written straight onto the page. It got a structure every case study follows.

Two calls the build turned on: the framework, and whether case studies have a shape.

The call	The easy answer	What we chose	What it cost, and what it bought
The framework	NuxtJS, the one Chris considered first.	Astro, on the stats Jake brought.	Leaving the framework he'd have reached for. The SEO the blog needs, and the speed, with components that work almost the same way.
Whether case studies have a shape	Write each one raw and render it straight onto the page.	One structure that tells a story, kept as records the site reads.	Harder to fit each different case study into it. Every case study reads the same way, so a visitor learns the structure once and digests the rest faster.

The call

The easy answer

What we chose

What it cost, and what it bought

The framework

NuxtJS, the one Chris considered first.

Astro, on the stats Jake brought.

Leaving the framework he'd have reached for.

The SEO the blog needs, and the speed, with components that work almost the same way.

Whether case studies have a shape

Write each one raw and render it straight onto the page.

One structure that tells a story, kept as records the site reads.

Harder to fit each different case study into it.

Every case study reads the same way, so a visitor learns the structure once and digests the rest faster.

04 Automation solution

Case studies aren't written any more. They're interviewed, and the answers become the page.

A personal game project took the time case studies need, and "it's not easy to just come out of thoughts, out of thin air." So we interview it away: Chris answers questions out loud, and everything is distilled into the data the page renders.

04.1 The pipeline

From a spoken answer to a finished page.

The pipeline from above: a recorded answer, the text it becomes, and the components it builds. The sections after it are the parts, what they replaced, and the calls behind them.

Each round
1. The questionsBuilt from the records
3. Chris answersOut loud, one question at a time
5. TranscribedWhisper, each answer to text
7. Into the recordsClaude, checked against the structureGaps leftNext roundAsks what's still open
1. Structure full
The case study
1. WrittenClaude, from every answer
3. ExportedRecords to the site's data
5. On the pageRendered as components
1. Chris reads the pageFixes go straight into the data

04.2 The parts

Five parts, and the last one is Chris reading the page.

What the pipeline is made of, as Chris meets it, and where each one runs.

The part	What it does	Where it runs
The questions	A round at a time, each built from what the last one left open.	The agent, from the records and the case study's structure.
The recorder	Takes each answer out loud, one question at a time.	Node.js.
The transcription	Turns each recording into text.	Whisper.
The writing	Distils the answers into records and writes the case study's data.	Claude.
The read-through	The one check: Chris reads the finished page and fixes what's wrong in the data.	On the site.

04.3 How it fits together

Each round asks what the last one left open, until the structure is full.

Round one's answers go into the records. Every round after is built from them, and the agent knows the case study's structure, so it asks until every part has material. Then the records are exported into data the template reads and renders: "which is beautiful, really."

04.4 The workflow shift

Every step from an idea to a case study, and what it takes now.

Each row is a step a case study passes through, how it used to run, and how it runs now. The thinking moved into the questions; the writing followed it.

	Before	After	What it saved
Gathering	Thinking it out of thin air: what to say, what to highlight, what to leave out.	Rounds of questions, each built from the last answers.	"It took 60% of the work away."
Structure	Working out the template while writing, flexible enough for every case study.	The agent knows the structure and asks until every part has material.	No template to hold in mind while writing.
Writing	Markdown files written by hand, up to two weeks a case study.	A draft on the page about 30 minutes after the interview.	About two hours to a case study in good shape.

04.5 The automation process

Asked, answered, written, and read on the page, with fixes made straight in the data.

Rounds of questions until the structure is full, then the page. The one check is Chris reading it, and so far it has caught nothing wrong: what it turns up is information with no component to show it yet, left visible on purpose to see whether it needs one.

Round one
Answers into the records
Rounds built on the records
Exported to the page
Chris reads the page

04.6 Automation decision

The easy way was to keep writing them. It got interviews, and fixes made by hand.

Two calls the pipeline turned on: who writes the case study, and what happens when the page is wrong.

The call	The easy answer	What we chose	What it cost, and what it bought
Who writes it	Chris, in Markdown files, one at a time.	An interview in rounds, and Claude writing from the answers.	Up to four rounds of questions, answered out loud. About two hours a case study, against up to two weeks.
When the page is wrong	Another round of questions.	Chris corrects it himself, in the component props and data.	The fixes stay his. "It's faster and easier."

The call

The easy answer

What we chose

What it cost, and what it bought

Who writes it

Chris, in Markdown files, one at a time.

An interview in rounds, and Claude writing from the answers.

Up to four rounds of questions, answered out loud.

About two hours a case study, against up to two weeks.

When the page is wrong

Another round of questions.

Chris corrects it himself, in the component props and data.

The fixes stay his.

"It's faster and easier."

05 Field notes

What people said about the site, and what building it comes down to.

What came of it: a first reader's words, the figures with one side, and what we took away.

Br*** S., on staging
Beautiful, professional, and, in his words roughly, it shows what a senior designer and developer can do, someone with a decade or more in the industry.
The one line
Portfolio of someone with over a decade of experience making websites.
In hindsight
Start with the interviews. Design and engineering plans come easily; writing something cohesive that tells a story and follows a structure doesn't, "because I am not writing every day."
Interview it away
"This is one of the most amazing things I've ever done, creating the interview workflow." Chris sees himself setting up more of it for the brands we work with next.
Page speed
PageSpeed Insights on the homepage, November 2026: 88 on mobile, 99 on desktop. Provisional: components added since the last check haven't been tuned, and a polish pass is planned before launch.
Over coffee
"When you create something that you care about, you need to give it the time to mature." Build a few parts here and there, "and from those parts you'd eventually see where you actually wanted to go."

06 Team and stack

Two people across design, engineering, and automation.

Built on Astro, SCSS, GSAP, Supabase, Resend, NodeJS, and Whisper. Made with Figma, Claude Design, Claude, and GitHub.

Built on: Astro · SCSS · GSAP · Supabase · Resend · NodeJS · Whisper
Made with: Figma · Claude Design · Claude · GitHub

Chris Javier Oliveros
Creative Director
Designed the site and built its front end, and built the automation behind it, the pipeline that distils his interview answers into the data each case-study page renders.
- PageSpeed Insights, 2026-11-05: 88 on mobile, 99 on desktop.
- A case study now takes about two hours from interview to a page in good shape, against up to two weeks when he wrote them by hand.
- Three case studies through the interview pipeline: about three hours for the first, two for the second.
Jake Christian Oliveros
CTO
Set up the backend, starting with the contact page: Resend receives the message, Supabase keeps the data and sends it back through Resend as a notification to Chris, over Supabase's custom SMTP. Made the case for Astro with its stats.

07 Impact

Up to two weeks a case study, by hand. Now about two hours, interview to page.

Each row is how a case study got made before and after. Nothing was timed with a tool: the figures are Chris's, and the first case study through the interview took longer than the ones since.

Time to a case study
per case study, to a page in good shape
About 2 hours
Before~~Up to 2 weeks~~
Through the interview
the first case study through it, then the second
About 2 hours
Before~~About 3 hours~~

Three versions that never shipped, and case studies that took weeks to write.

Started in May 2026, rebuilt around interviews in October, and launching in December.

A fourth attempt, by a studio that had never needed a portfolio.

Version four

Word of mouth

Why now

Who it's for

Every screen of the site, shown whole.

From Figma to Claude Design and back, until it was right.

The first try was isometric, and the easy picture was a screenshot. It got a blueprint, and diagrams.

From the design to a live page, and from the contact form back to Chris.

The parts, and where each one runs.

The design names the components, the records hold the words, and the template puts them together.

The easy build was a case study written straight onto the page. It got a structure every case study follows.

From a spoken answer to a finished page.

Five parts, and the last one is Chris reading the page.

Each round asks what the last one left open, until the structure is full.

Every step from an idea to a case study, and what it takes now.

Asked, answered, written, and read on the page, with fixes made straight in the data.

The easy way was to keep writing them. It got interviews, and fixes made by hand.

Br*** S., on staging

The one line

In hindsight

Interview it away

Page speed

Over coffee

Chris Javier Oliveros

Jake Christian Oliveros

Time to a case study

Through the interview