Why I'm building OneSlate

Calendly is great if you're a freelancer with one calendar.

It breaks if you're an executive with shared calendars from your
team — which is exactly my situation. I run a small company and
have shared calendars from ~10 colleagues. When I create a Calendly
link, every "shared" event gets treated as my own busy time.

The result: my Calendly booking page often shows zero available
slots. People who try to schedule with me give up. I've had to
manually email back-and-forth more times than I can count.

OneSlate solves this with a simple but specific filter: only
calendars where calendar_kind is primary or owned count
toward your busy time. Shared calendars are visible to you in
the dashboard, but they don't pollute your booking page's
availability.

That single insight is the core differentiator. Everything else
in OneSlate — multi-account integration (Google + Microsoft),
mobile-first UX, scheduling links — is built on top of solving
that specific executive problem.

The setup

• Solo founder, ~1 month into OneSlate's development
• Day job: building MVPs for early-stage startups
• Stack: Next.js 14, Supabase, Tailwind CSS, SWR
• AI tools:
  • Claude (claude.ai) — design, strategy, prompt engineering, decision support
  • cowork (Anthropic's coding agent) — implementation, testing, git operations, deployment
• Hosting: Vercel (auto-deploy from main)
• Repository: just me, pushing to main with feature flags

The 14 features I shipped that day

Morning session (3 hours)

1. CreateEventModal — multi-calendar event creation with recurrence, attachments, video conferencing URL auto-generation
2. Public booking page bug fixes — 4 critical issues including timezone display, all-day events blocking slots, and grid hardcoding
3. Logged-in viewer feature — when an OneSlate user views someone else's booking page, their own calendars overlay automatically (no OAuth needed). This is the Calendly-killer.
4. Scheduling-pages regression fix — PATCH 400 error from a PostgreSQL time format mismatch
5. Colleague calendar exclusion — the calendar_kind filter I described above. Applied across PC dashboard, mobile, and public booking page.

Afternoon session (3 hours, between client calls)

1. Mobile UI specification v2 — comprehensive 5-phase plan, created with Claude over coffee
2. Phase 1: Mobile foundation — MobileLayout, MobileBottomNav, MobileHeader, FAB, safe-area utilities
3. Phase 2: Mobile dashboard — including a 6-hour debugging detour that I'll describe below
4. Feature Flag system — lib/feature-flags.ts with ALPHA_EMAILS = ['onojun.s@gmail.com'] for safe rollout
5. Preview/main deployment workflow — operational rules for cowork to push directly to main with alpha gating

Late evening session (2 hours)

1. Phase 3a: Team project mobile UI — project list, member management, invitation flow
2. Phase 3b-1: Availability + bookings tabs — team scheduling coordination
3. Phase 3b-2: Personal scheduling links mobile — the Calendly-replacement core, now mobile-first
4. UI polish — toggle position fixes, Outlook HTML tag stripping (Outlook returns body.contentType="html" by default), past event handling

The collaboration pattern

This is the part most people get wrong when they try to use AI
agents.

Layer 1: Strategy with Claude

I'd open claude.ai during a coffee break or between calls.
We'd discuss:

• UX edge cases (what happens with Outlook all-day events?)
• Prioritization (Phase 2 mobile dashboard vs. UX polish?)
• Technical trade-offs (sticky header vs. flex-col restructure?)
• Edge cases (what if the user's primary calendar isn't the default selected?)

The output of these conversations was a detailed cowork prompt
— often 200-400 lines — with specific files to touch,
acceptance criteria, what NOT to break, and operational rules.

Layer 2: Implementation with cowork

I'd paste the prompt into cowork. It would:

• Read the relevant files
• Write the code
• Run npx next build to verify type checks
• Commit with a descriptive message
• Push to main
• Wait for Vercel to deploy

Total time: 30-60 minutes per feature, depending on complexity.

While this ran, I'd go back to client work. Two streams
running in parallel.

Layer 3: Real device verification

After cowork reported "done," I'd verify on iPhone. This is
where the magic — and the bugs — surfaced.

PC testing missed:

• Outlook events showing raw HTML tags in descriptions
• Past events polluting the "today" view
• Toggle UI overflow on the right edge of cards
• Mobile event creation reflecting in colleague's calendar but not the creator's own
• Mobile event detail tap doing nothing (no onClick handler)

Real device testing caught all of these. The pattern: design
in Claude, implement in cowork, verify on iPhone, iterate.

Key moments — the wins

The "colleague calendar leak" insight

This is OneSlate's reason to exist.

I noticed it because I have the problem. When I tried using
Calendly for myself, it showed me as busy 24/7 because of
shared calendars I never even attend.

So I built a calendar_kind enum: primary, owned, or
shared. The availability calculation only considers the first
two. Shared calendars are visible to me in the dashboard for
context, but they don't pollute my booking page.

This took ~30 minutes to design with Claude and ~1 hour to
implement with cowork. Calendly has been around since 2013
and still doesn't solve this. It's a small change with big
implications.

The Calendly-killer feature

When you're logged into OneSlate and view another OneSlate
user's booking page, your calendars automatically overlay on
their availability — no OAuth dance, no extra clicks. You
see in real-time when both of you are free.

Calendly can't do this because they don't have your account
context when you're booking on someone else's page. OneSlate
does, because both of you are users.

This is the kind of feature you only think of when you're
both the user and the builder.

Feature Flags as a force multiplier

After the PostCSS event (described below), I built a feature
flag system in 30 minutes:

export const ALPHA_EMAILS = ['onojun.s@gmail.com'];

export const FEATURE_FLAGS = {
  MOBILE_DASHBOARD: 'mobile_dashboard',
  MOBILE_TEAM: 'mobile_team',
  MOBILE_SCHEDULING_PAGES: 'mobile_scheduling_pages',
  MOBILE_SETTINGS: 'mobile_settings',
} as const;

export function isFeatureEnabled(flag: FeatureFlag, email: string) {
  return ALPHA_EMAILS.includes(email);
}

This single pattern unblocked everything. I could push experimental
features to production main without risking regular users. New
mobile UI? Gated to my email. Test, iterate, refine, then expand.

This used to require a staging environment, OAuth redirects,
and a complex deployment workflow. With feature flags, it
requires one if-statement.

Key moments — the failures

The PostCSS event (lost 6 hours)

After implementing Phase 2 mobile dashboard, production CSS
dropped to 2.1KB. The site loaded but had zero Tailwind styles.
Times font, no spacing, completely broken visual.

I spent 6 hours debugging:

• Tailwind config? Looked fine.
• Component imports? All correct.
• Vercel deployment? Reporting success.
• Build cache? Cleared multiple times.

Root cause: postcss.config.mjs was missing entirely from the
project. Tailwind directives were never being processed during
build. Locally, Vercel's CDN was serving cached CSS, masking
the problem.

The cowork agent had been writing Tailwind classes for weeks
without ever checking that the PostCSS config existed.

Lesson: AI agents work within the assumptions of the project.
They don't always verify those assumptions. Always check the
build pipeline yourself when something breaks unexpectedly.

The Outlook HTML rendering bug

iPhone testing revealed event descriptions showing raw HTML
tags:

<html><head><meta http-equiv="Content-Type"
content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft
Exchange Server">...

Microsoft Graph API returns event bodies with
contentType: "html" by default. We were rendering the raw
string as text. Looked terrible on a phone.

Fix: a small HTML-to-text utility that strips tags, preserves
line breaks, and falls back to "(no description)" for empty
HTML payloads.

Lesson: Real device testing is non-negotiable. PC simulators
treat content like the developer expects. Phones treat content
like users expect.

The position: sticky disaster (a separate day)

This is the painful one.

I tried to add sticky calendar headers — the basic Google Calendar
feature where the day labels stay visible while you scroll.
This took me five attempts across two sessions, and I never
got it working.

What I tried:

1. position: sticky on the header group
2. Restructuring to flex-col with extracted header
3. Changing parent overflow: hidden to overflow: clip
4. Discovering a hidden overflow: hidden on a hidden md:block wrapper
5. Increasing hour cell height so scroll would actually trigger

The root cause was a chain of overflow: hidden ancestors that
break sticky positioning, combined with a containing block
hierarchy I never fully mapped.

After 6+ hours of debugging across the day, I reverted everything
and shipped without sticky headers. It's still on the backlog.

Lesson: Sometimes "ship the working version" beats "perfect
it now." Sunk cost is real even with AI tools — maybe especially
with AI tools, because each retry feels like it should be the
last one.

What I actually learned

After a month of building OneSlate this way, here's what's
clear:

1. Side projects benefit massively from AI agents.
   The 30-60 minute cowork sessions fit perfectly into the
   gaps in client work. I'm not "coding all day" — I'm
   directing AI agents in 5-minute chunks throughout the day.

2. Clear specs compound.
   Detailed Claude conversations make cowork output
   dramatically better. A 200-line prompt with acceptance
   criteria produces 90% correct code. A vague prompt
   produces something that compiles but misses the point.

3. Feature flags = freedom to ship.
   Alpha gating lets you push to main without risking anyone.
   This pattern alone changed how aggressive I am with
   shipping.

4. Real device testing is non-negotiable.
   PC simulators miss too much. Especially on mobile.
   Especially with edge cases like Outlook events or
   timezone-sensitive UI.

5. Know when to walk away.
   I burned 6 hours on sticky header. Reverting was the
   right call. AI tools don't change the fact that some
   problems are not worth solving today.

6. Solo founder ≠ alone.
   Claude is the design partner. cowork is the implementation
   team. This used to require 3 people. Now it requires me
   and a coffee shop.

What's next

• Beta: currently at 1 user (a friend), scaling cautiously to 5-10 over the next two weeks
• Bilingual launch: English and Japanese (built-in, with locale detection at the OGP layer)
• Pricing: free during beta, subscription tiers planned post-validation

Looking for feedback from:

• Indie hackers building scheduling tools
• Executives who've felt the Calendly pain
• Anyone building solo with AI agents

Try it

oneslate.tech — free during beta,
sign up takes 30 seconds.

If any of this resonates, I'd love to hear from you.
Reach out on X: @onojunichiro

*About me: CEO ONESLATE LLC([https://oneslate.tech/]),
building MVPs for startups in Japan and globally.
OneSlate is what happens when I get tired of my own
calendar problems. X account is @Ao_ai_schedule.
*