Tattoo Artist CRM - Ideation

Introduction

I’ve been getting a bunch of tattoos recently and obviously that means I’ve been talking with my artist (highly recommend!) as well as being in the parlour a lot, I came to realise that the artists struggle with managing their clients and appointments. They have to deal with messaging clients across multiple platforms (Instagram, WhatsApp, Email, etc.), manage their time meticulously and keep up with their client’s ever changing ideas. If there was a platform to bring all these things into one place, it would make their lives a lot easier. So I’ve decided to build a “CRM” for tattoo artists. This blog will be a series of posts that will document the journey of building this app.

How I start a project

The Problem

It’s always tempting to start writing code straight away but I’ve found that it’s better to take a step back first and do a little planning. A product is for someone and it’s important to understand who that someone is. I don’t go as deep as creating personas but I do like to write down what is the problem I’m trying to solve and who is it for. This helps me keep the project focused and not get lost in the weeds.

I’ve become a big fan of Mind Maps as they are free flowing and can be as detailed or as high level as needed. Sometimes a “subject” is just a single phrase and sometimes it needs to be broken down and investigated further and a Mind Map allows for that flexibility while keeping everything on screen at once. My go to is XMind but there are plenty of other tools out there.

Features

Once I have spent a little time thinking about the problem space I then write out the features and every feature should match up to at least 1 pain point or problem. This is my favourite part of the process as this is where the project really starts to take shape. I can see the screens in my head and I can start to think about how the user will interact with the app. I try not to think about technical limitations (both in terms of what is possible and what I can personally do) as more often than not, it is possible and I wouldn’t want to limit the project.

In the case of this app, there were quite a few features that I wanted to include but because this is a side project I need to be realistic about what I can achieve (at least to begin with). So I’ve selected just the core features that will be my MVP (see Mind Map below). I’ve been stung in the past by trying to do too much and ultimately not doing anything because it feels so overwhelming and I’m usually working on these in the evening when I’ve already been working all day.

Schema

The next step is to design the database schema. It doesn’t have to be perfect but it’s a good idea to understand the relationship between different entities. I’m not hugely experienced in database design but I’ve found using dbdiagram.io to be really helpful. It’s a great way to visualise the data and see if there are any issues with the design. I have also found ChatGPT to be really helpful here. I just give a basic description of the app and then copy and paste the entire schema into the chat and ask for feedback.

Some key points about the schema:

• I plan to have both Artist and PotentialClient users. Although the MVP will only have the Artist user I still wanted to design the schema with the PotentialClient user in mind.
• The Artist and PotentialClient many-many relationship is managed with a intermediary table Client.
• Each Client can have multiple Projects which in turn can have multiple Sessions.
• This will definitely change as the project progresses but it’s a good starting point.

Tech Stack

Of course I’m choosing Flutter as the front end framework. It’s what I know best and I don’t see a reason to use anything else for this project. I expect to deliver it primarily as a web app but I think a mobile (and even desktop) client would be really useful.

For the backend I’m going to use Appwrite. I’ve only played with it once but I was impressed with how easy it made things. The main issue I had with it was handling complex relationships but I don’t think project will have that many complex relationships so I think it will be fine.

I was tempted to try out Supabase or even Serverpod but I wanted to keep it simple. I will try to write my code as backend agnostic as possible so I can switch if need be.

Addressing unknowns

Before progressing any further I like to address any unknowns that I have. This could be anything from a new technology that I want to use, a feature that I’m not sure how to implement or a design decision that I’m not sure about. I find that if I don’t address these unknowns early on then they can become blockers later on in the project (or worse, mean the project can’t be completed).

Instagram messaging

One of the core features is having a centralised messaging system and one of the main messaging platforms for artists is Instagram. I’ve tried integrating Instagram into a Flutter app before and it was not easy to say the least and I didn’t actually succeed. However, I did some more research and found some articles and SO threads that show it is possible. Basically it seems like I need to use a WebView (or in the case of web, open another tab/window) and then intercept the redirect URL to get the access token. I could also just handle the redirect with a serverless function. I can then use this token to make requests to the Instagram API. The main question right now is whether to do this all on the server or have the client make the requests. There are pros and cons to each and will be a good topic for a future blog post once I’ve made the decision.

Gmail/Calendar integration

Like Instagram, most artists have a Gmail account and use Google Calendar to manage their appointments. I’ve never used the Google APIs before but there seems to be a lot of documentation and a Flutter package so I’m not too worried about this and I have confirmed they have the endpoints/features I need.

I also don’t fancy writing a calendar widget from scratch so I found this package that looks very promising.

Next Steps

The next steps are going to be wireframing. I personally prefer to go with some low fidelity outlines to get an idea of the layout and then just go straight into coding. I find Flutter to be very flexible and I can make changes on the fly so I don’t see the point in spending too much time on high fidelity prototypes because it would be quicker for me to just code it.