Building a Calendly alternative on the side: 14 features in one day with Claude

Ao oneslate — Tue, 05 May 2026 06:55:06 +0000

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)

CreateEventModal — multi-calendar event creation with recurrence, attachments, video conferencing URL auto-generation
Public booking page bug fixes — 4 critical issues including timezone display, all-day events blocking slots, and grid hardcoding
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.
Scheduling-pages regression fix — PATCH 400 error from a PostgreSQL time format mismatch
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)

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

Late evening session (2 hours)

Phase 3a: Team project mobile UI — project list, member management, invitation flow
Phase 3b-1: Availability + bookings tabs — team scheduling coordination
Phase 3b-2: Personal scheduling links mobile — the Calendly-replacement core, now mobile-first
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:

position: sticky on the header group
Restructuring to flex-col with extracted header
Changing parent overflow: hidden to overflow: clip
Discovering a hidden overflow: hidden on a hidden md:block wrapper
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:

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.
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.
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.
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.
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.
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.
*

DEV Community: Ao oneslate