Day 01: Foundation and First Pixels

Day 1 is done. The foundation is in place, and the first version of the hero section is live.

What Got Built

Today was all about getting the basics right:

  • Project initialization with Astro 5.x, TypeScript, and Tailwind CSS 4.x
  • Design system implementation with custom color palette and typography
  • Lighthouse CI setup for continuous performance monitoring
  • Hero section with Japanese aesthetic principles (Ma and Kanso)
  • Property-based testing for design system compliance
  • Performance optimization balancing brand identity with speed

During these 26 days, the work-in-progress site is hosted at 26to26.shikadigital.co.jp — a staging subdomain where you can follow along in real-time. Once complete, it’ll replace the main shikadigital.co.jp site.

The Design System

The Shika Digital design system is built around simplicity and contrast:

@theme {
  /* Color Palette */
  --color-black: #000000;
  --color-off-white: #f5f5f5;
  --color-dark-gray: #333333;
  --color-light-gray: #cccccc;
  --color-teal: #14b8a6;
  --color-yellow: #fbbf24;

  /* Typography */
  --font-body: 'Jost', sans-serif;
  --font-heading: 'Zen Kaku Gothic New', sans-serif;

  /* Transitions */
  --transition-fast: 200ms;
  --transition-normal: 300ms;
  --transition-slow: 500ms;
}

This configuration lives directly in global.css for Tailwind v4 compatibility, replacing the traditional tailwind.config.js approach.

Japanese Aesthetic Principles

The hero section embodies two key principles:

Ma (間) — Negative space as an active design element. The hero uses full viewport height with generous whitespace, letting the message breathe.

Kanso (簡素) — Simplicity and elimination of clutter. Every element serves a purpose: eyebrow text for context, headline for impact, pain points for empathy, promise for hope, and CTA for action.

<section class="relative min-h-screen flex items-center justify-center">
  <!-- Subtle grid pattern background -->
  <div class="absolute inset-0 bg-[linear-gradient(to_right,#80808012_1px,transparent_1px),linear-gradient(to_bottom,#80808012_1px,transparent_1px)] bg-[size:24px_24px]"></div>
  
  <!-- Content with intentional spacing -->
  <div class="relative z-10 max-w-4xl mx-auto px-6 py-20">
    <!-- Eyebrow, headline, pain points, promise, CTA -->
  </div>
</section>

Testing Strategy

I’m using property-based testing for the design system, which is different from traditional unit tests.

Unit tests check specific examples:

// Unit test: Check one specific case
test('button has correct padding', () => {
  expect(button.padding).toBe('12px 24px');
});

Property-based tests check rules across many generated examples:

// Property test: Check the rule holds for ANY color combination
fc.assert(
  fc.property(
    fc.hexaColor(), // Generate random colors
    fc.hexaColor(),
    (fg, bg) => {
      const contrast = calculateContrast(fg, bg);
      // The PROPERTY: contrast must always meet WCAG standards
      return contrast >= 4.5 || contrast >= 3.0;
    }
  )
);

Property-based testing generates hundreds of random inputs and verifies the rule holds for all of them. It catches edge cases you wouldn’t think to write unit tests for.

For the design system:

  • Color contrast tests verify WCAG AA compliance (4.5:1 for normal text, 3:1 for large) across all possible color combinations
  • Touch target tests ensure interactive elements meet 44x44px minimum with various sizes
  • Responsive typography tests validate fluid scaling with clamp() across viewport ranges
  • Design system tests check color palette and font family consistency

All 24 tests passing on Day 1, with fast-check running 100 examples per property.

The Performance Trade-off

Here’s where it got interesting. Lighthouse CI initially failed because Google Fonts (Jost and Zen Kaku Gothic New) hurt mobile performance scores.

The options:

  1. Remove Google Fonts → Lose brand identity
  2. Self-host fonts → More complexity, maintenance burden
  3. Accept the trade-off → Document it and move on

I chose option 3. The brand typography is essential to Shika Digital’s identity. The performance hit is real but acceptable:

  • Desktop: 90%+ performance score
  • Mobile/throttled: ~60-70% performance score

It is interesting that the performance issues are only local, once I published the site on Sevella, the scores are now 94 on Mobile and 99 on Desktop.

Tailwind v4 Migration

Migrated from tailwind.config.js to inline theme configuration in global.css. Tailwind v4’s new approach consolidates everything into CSS:

@import "tailwindcss";

@theme {
  /* All theme configuration here */
}

/* Global styles */

Cleaner, more maintainable, and aligns with modern CSS practices.

Build Optimization

Added Astro build configuration for better performance:

export default defineConfig({
  build: {
    inlineStylesheets: 'auto',
  },
  vite: {
    build: {
      minify: 'esbuild',
    },
  },
});

This enables esbuild minification, and HTML compression — every byte counts.

Project Governance

Created steering documentation to keep the project on track (the later three are standard ones in Kiro):

  • definition-of-done.md — Quality criteria and acceptance checklist
  • product.md — Positioning, pillars, and target audience
  • structure.md — Project layout and conventions
  • tech.md — Tech stack and common commands

These live in .kiro/steering/ and guide every decision going forward.

What I Learned

1. Tailwind v4 is different. The migration from config files to inline CSS took some adjustment, but it’s cleaner once you get it.

2. Performance is about trade-offs. Perfect Lighthouse scores don’t matter if the site loses its identity. Know what you’re optimizing for.

3. Property-based testing catches edge cases. Fast-check found issues I wouldn’t have thought to test manually.

4. Documentation prevents drift. Writing down the “definition of done” early saves arguments with yourself later.

Tomorrow: Content Structure

Day 2 will focus on:

  • Setting up the content collections for case studies and services
  • Building the navigation and footer components
  • Creating the about page structure
  • Implementing the progress tracker component

The foundation is solid. Time to build on it.

This is Day 1 of 26. December 6, 2025.