What it does
Squiddies is a CRM for tattoo artists. It tracks clients, projects, and multi-session tattoo work. Artists set their weekly energy capacity, and the app shows how much is used as sessions are booked—preventing overbooking before it happens.
The app syncs with Google Calendar, sends push notifications for appointments, and includes quiet hours to block notifications during rest time. A burnout mode provides emergency schedule protection when needed. The UI is designed with neurodiverse users in mind.
Inspiration
I watched my tattoo artist struggle with the constant pressure to stay online, fearing they'd miss client messages. Their entire studio managed schedules on a shared Google Calendar, functional, but far from optimized. Most existing CRMs target studios as businesses, not individual artists as creative professionals.
What struck me most; my artist, like many in the studio, has ADHD. Time management tools designed for neurotypical brains weren't just unhelpful, they added to the overwhelm. I wanted to build something that works with how creative, neurodiverse minds actually function.
Research
I analyzed CRM platforms both inside and outside the tattoo industry. I researched UX patterns for neurodiverse users—and found that most "ADHD-friendly" advice just restates general UX principles without specifics.
So I went directly to the source: ongoing conversations with my artist and others with ADHD throughout development. Key insights shaped the design:
- Energy bars deplete, not fill — A rising bar feels like a goal to reach; a depleting bar matches how energy actually feels
- Positive reinforcement matters — More celebration moments planned for future updates
- Customization reduces friction — Light/dark modes now, more color themes coming; four calendar views to match different thinking styles
Key features
- Energy tracking — Weekly capacity depletes as you book sessions. Calendar time is categorized into chair hours, drawing hours, and holidays—all counted toward your energy budget
- Google Calendar import — Pull in events and process bookings without switching apps
- Quiet hours — Absolute notification blocking when you need to focus or rest
- Burnout mode — Emergency schedule protection that's 100% distraction-free
- Client & project management — Track clients, multi-session projects, reference images, and session history
- Smart dashboard — Shows only what needs your attention today. No overwhelm.
- Task management — Todos prioritize energy cost over rigid due dates
Extra care has been put in for artists with ADHD and other neurodiverse conditions: easy-to-read typography, purposeful iconography, multi-page forms that break complexity into steps, multiple calendar views to match different thinking styles, and a gentle onboarding wizard that configures work days, office hours, quiet hours, and notifications one step at a time.
What makes it a "Flutter Butler"
Squiddies acts as a digital butler for tattoo artists by:
- Remembering everything — Client details, preferences, project history, so the artist's brain doesn't have to
- Protecting boundaries — Quiet hours and burnout mode enforce rest without guilt
- Preventing overcommitment — Energy tracking warns before you overbook yourself, and the scheduling wizard suggests times that respect both artist energy levels and client preferences
- Surfacing what matters — Dashboard filters noise to show only today's priorities
It's the assistant that manages the business side so artists can focus on creating art.
How I built it
Squiddies is built with Flutter and Serverpod 3.x in a monorepo architecture:
- Flutter frontend — Mobile and web support with Riverpod state management and go_router navigation
- Serverpod backend — JWT authentication, Google OAuth, complex entity relationships (Artists → Clients → Projects → Sessions)
- Serverpod web server — Landing page, Terms & Conditions, and Privacy Policy served directly from the backend
- External integrations — Google Calendar import with webhooks, AWS S3 for file uploads, Firebase Messaging for push notifications
- Scheduled operations — Serverpod future calls for appointment reminders and notifications
- Shared code — Notification payload types shared between server and client, plus a shared datetime utility package
Challenges
- Energy system UX — Designing an energy system that feels intuitive. I landed on a depleting bar (like a battery) rather than a filling bar after user feedback that rising bars felt like goals to achieve
- Shared calendar filtering — Since entire studios share one Google Calendar, I built custom filters so artists only get notified about sessions relevant to them. New events land in an inbox for later review and conversion to app-specific events
- Google Calendar webhooks — Real-time sync integration for immediate calendar updates
- Performance optimization — Originally each calendar view had its own endpoint, causing redundant data fetches. Consolidated to a single endpoint returning a sealed class DTO with in-memory caching for faster performance and fewer network calls
- Neurodiverse-friendly forms — Building forms that don't overwhelm users, solved with multi-page progressive disclosure
- Firebase Messaging payloads — FCM data payloads require
Map<String, String>, which needed careful serialization. The monorepo architecture paid off here—shared code between server and client meant writing serialization/deserialization logic once - Cross-linked entity management — Sessions, clients, and projects are deeply interconnected. Building flexible shared widgets prevented logic duplication, and careful state management ensures that when one entity updates, all related data refreshes correctly across the app
What's next
- Instagram DM integration for unified client messaging
- AI assistant for natural language queries ("When did I last see Alex?")
- Automated pre-appointment emails
- Public booking page with energy-aware availability
- Undo functionality for most actions (architecture already in place) — reducing anxiety about mistakes with an 8-second "undo" window
- Full studio management portal
Testing
For testing, you can either create a new account of use the email and password mentioned in the repo README.md which has some pre-populated data.
Built With
- amazon-web-services
- dart
- firebase
- flutter
- s3
- serverpod
Log in or sign up for Devpost to join the conversation.