Inkbook

Inkbook is a booking app for service providers, starting with the tattoo artist niche. The project began with a real problem a friend who tattoos surfaced; he's the validation customer. Tattoo artists are a tight, specific market with strong word of mouth, which makes the niche a good wedge before expanding to others running appointment-based small businesses.

Today, he runs his business across three disconnected tools: Squarespace for his public site and portfolio, Typeform for client intake, and Square Booking for scheduling and deposits. Clients commit detailed information across all three — intake forms, tattoo ideas, consent and waiver — before they ever confirm the thing they actually care about. Is the artist available when I am?

I'm working as a solo designer and builder on Inkbook, with AI as a collaborator across strategy, implementation, and design refinement. It's the first project where I'm acting as every role on the team, made possible by AI compressing the execution work that would normally require a small team. The goal is to first validate the product with a small group of independent tattoo artists before expanding to others, building only what's needed to prove the concept and deferring the rest until use earns it.

The friction isn't that booking is hard. It's that the booking flow is split across three tools that don't know about each other.

On Squarespace, a client browses an artist's portfolio and decides they want a tattoo. To book, they're sent to Typeform, where they fill out a detailed intake: tattoo idea, size, placement, reference images, consent and waiver, contact info. After submitting, they're shown a link to a separate Square Booking page. That link is where most people quit. Some miss it entirely. Some assume they've already booked. Some are just done filling out forms. The ones who do click through finally see the artist's calendar, only to discover whether the artist is actually available when they are.

Three tools, three sets of expectations. Availability — the thing that mattered most — answered last. The product opportunity isn't to build a better intake form. It's to put availability before commitment, and let everything else collapse into a single, coherent flow.

The redesign needed to do two things at once: solve the booking flow as a product, and validate that solution with real artists before building toward parity with what they currently use.

Scope and posture

Before designing anything, I made a discipline call: validation before feature parity. Squarespace, Typeform, and Square Booking each do dozens of things their users have come to depend on. Trying to match that surface area on day one would have meant a year of building before any artist could meaningfully test the product. Instead, I scoped the first version to the booking flow itself, plus the absolute minimum needed to make it real for an artist: a unique booking URL they could share on social media or their existing site, an intake collected at the right moment, and a deposit. Everything else — recurring availability rules, multi-artist support, a portfolio surface, marketing site features, reporting — was deferred until use earned it.

The architectural move

The product insight was simple, but it shaped everything that followed: put availability before commitment. Today, clients commit detailed information across multiple tools before they ever know whether the artist is available. In Inkbook, the flow flips. A client lands on the artist's page, sees real availability, and selects a slot. Only then are they asked for the intake details, consent, and deposit. Reframing the order changed almost every other product decision: what data we collect, when we collect it, what the artist sees, what the client sees, and where deposits get held. Once availability was the entry point, the rest of the product had a natural shape.

Working with AI

The job isn't using AI. It's deciding which collaborator does which work. I work with three: a strategy collaborator I think out loud with about scope, sequencing, and tradeoffs; an implementation collaborator that turns shaped designs into working Next.js, React, and Supabase code; and a design refinement collaborator I use to pressure-test patterns and copy. The discipline is in the handoff between them. AI compresses the execution work that would normally take a small team. It does not compress the thinking.

The decision about how to architect payments is a good example. Inkbook's job is to facilitate deposits, not to hold them. Artists should be paid directly, and Inkbook shouldn't sit in the middle of a transaction it isn't a party to. Stripe Connect made that possible. The real question was Connect Express, which simplifies artist onboarding and gives Inkbook more control over the experience, or standard Connect, which has more setup friction for the artist but keeps disputes between artist and client where they belong. Connect Express was the easier short-term call. Standard Connect was the right one: accepting more onboarding friction now in exchange for a cleaner role for Inkbook long-term. AI surfaced the tradeoff faster, but the call was mine to make.

As of writing, Inkbook has a working end-to-end booking flow. A client can land on an artist's URL, see real availability, select a slot, complete the intake at the right moment, sign consent and waiver, and pay a deposit. Artists onboard through Stripe Connect, receive bookings, and get email confirmations. Google Calendar integration syncs both directions: personal commitments — vacations, appointments, blocked days — keep clients from booking unavailable times, and confirmed bookings push back to the artist's calendar so they don't have to log into Inkbook or manually transcribe appointments.

The product has been tested with my co-founder, several engineering friends giving feedback, and consistent internal testing. Real artist validation beyond my co-founder is the next milestone.

What's next

The current focus is the polish features that emerged from real use, mostly things my co-founder pointed out from Square Booking that he genuinely depends on: a client-side rescheduling flow, SMS reminders through Twilio, custom appointment responses, the ability for artists to create an appointment directly (especially in-shop, mid-conversation, when a client wants to lock in a follow-up), and a way to handle abandoned bookings before they're lost. A simple marketing site and a more polished onboarding experience are also on the near-term list.

What I'm wrestling with

Two questions are open and worth naming. The first is "how good is good enough." I care about the pixels, and the temptation to keep refining before showing real artists is strong. But validation has to come before polish, and shipping something good enough to test is more useful right now than shipping something I'm proud of.

The second is MVP scope. Square Booking has years of features artists rely on, and matching that surface area would take a year of solo building before any artist could meaningfully test the product. The discipline is to keep deferring features until use earns them, even when a real artist asks for one. My hypothesis is that the core flow, done well, saves artists enough time managing their schedules that the missing features are tolerable. Real artists testing it is what will tell me whether that's true.

Inkbook is the first project where I've operated outside the normal designer–engineer–PM triad I've worked in for most of my career. The most useful insights have been about the discipline that solo work requires.

The first is about validation. Every instinct as a designer is to refine before showing, especially when the user seeing it is your co-founder, and especially when you care about the work. But a few real users beat ten hypothetical ones. Solo thinking has limits, and the only way past them is to put the product in front of someone who isn't me. Inkbook has reinforced that the right time to show real users is sooner than feels comfortable.

The second is about working with AI. AI compresses the parts of building that used to require a team. But the parts that matter most get harder, not easier, when there's no one to push back: knowing what to build, deciding which tradeoffs are worth making, choosing what to defer. The discipline isn't just in the handoff between collaborators; it's in resisting the temptation to let AI's speed substitute for slower, harder thinking.

The third is about systems. Even on a solo project, I built Inkbook as a system. The components, the data model, the payment architecture, the calendar logic — each was designed to be reused, extended, and replaced. That instinct comes from a decade of design systems work, and it's served me well here. A solo founder can move fast, but only if the foundation can carry whatever they ship onto it next.