How I built PMU Forms in six weeks and grew it to $1,200 MRR

PMU Forms is a subscription product for permanent makeup (PMU) artists. It replaces the paper consent and intake forms that every client fills out before a procedure. I built it as the contract lead and CTO for iShapeBrows. The first production version, a Swift iOS app and an Angular web app, took six weeks.

Over its life it grew to $1,200 in monthly recurring revenue from App Store subscriptions. More than 1,800 artists signed up, they added more than 6,000 clients, and those clients filled out more than 53,000 forms. The app held a 4.3 rating from 37 ratings and was live on the App Store from 2020 until 2024.

If you’re a founder trying to decide who should build your app, this post is about the decisions behind those numbers.

The problem was narrow, and that helped

Permanent makeup artists need signed consent and intake forms for every client. On paper, those forms get lost, are hard to read, and can’t be searched. The job was not “build software for PMU artists.” The job was “get a client from walking in the door to a signed, stored form, with no paper.”

A narrow problem is a gift. It tells you what to build first and gives you a clear reason to say no to everything else.

What I built first and why

The first version had two parts.

An iPad and iPhone app for the artist. Artists work in a studio with a client sitting in front of them. A tablet they can hand to the client is the natural tool, so the artist app came first and it was native Swift with UIKit. I went native because the core moment, the client signing on the device, had to feel solid. A clumsy signature screen at the point of consent undermines trust in the whole product.

A web portal for the client. Clients don’t want to install an app to fill out one form. An Angular app on Firebase Hosting let them log in, book, fill out their forms and take before photos with their webcam, all from a browser.

For the backend I used Firebase: Auth (with Google, Facebook and phone sign-in), Firestore, Storage, Cloud Functions, Analytics and Crashlytics. On a six-week timeline, writing a custom backend for login, file storage and data sync would have eaten most of the schedule. Firebase covered all of that, which left the time for the parts that were specific to this product.

That’s the main judgment call in any short build: spend your custom engineering on what makes the product different and rent everything else.

The core flow

The product as it grew was built around one chain of steps:

1. The artist sets up services and assigns forms to each service.
2. The artist books an appointment for a client.
3. The client fills out the forms for that service and signs on the device.
4. The artist countersigns.
5. The form locks after signing, so nobody can change it later.
6. The artist can view or print it as a PDF whenever they need it.

Locking forms after signing was a deliberate choice. A consent form that can be edited after the fact isn’t worth much. The lock costs some flexibility, and it’s the right tradeoff for a legal document.

Around that core, artists got client notes with photos, a shareable link to their own form page, in-app tutorials, and LiveChat support inside the app.

What waited

Editable form templates are a good example of something that could have gone into the first version and didn’t. They shipped in 2023.

From my side, the reasoning is simple. A form editor is a big feature: a builder UI, validation, and the question of what happens to forms that were already signed under an older version of a template. Getting artists signing forms on day one mattered more than letting them redesign the forms.

Versioning is the part of templates that matters most. A .NET C# API, running in Docker on AWS, handled versioned form templates. A signed form needs to point at the exact template the client saw, not whatever the template looks like today.

The order of work after launch was driven by users. In January 2022 we ran an email survey of artists, and the answers fed later improvements. I would much rather build from what paying users say they need than from a list we wrote before anyone used the product.

Protecting the data

These forms are records that artists may need years later. So beyond Firebase’s own guarantees, there were daily automated Firestore backups. It’s not a feature anyone sees, and it’s one of the first things I’d set up again for any app that stores documents people depend on.

How the app made money

PMU Forms was a monthly subscription sold through the App Store with StoreKit in-app subscriptions.

I like this model for a product like this, for two reasons. First, artists use it with every client, so a monthly charge matches the ongoing value they get. Second, letting Apple handle billing meant we didn’t need to build payment pages, card storage or subscription management for the first version. Apple takes a cut, and in exchange you get a checkout that customers already trust and no billing code to maintain.

That model carried the product to $1,200 MRR. It’s not a venture-scale number, and it doesn’t need to be. It’s a small, focused product that real businesses paid for every month, across several years.

Support is part of the product

Artists are not developers, and a product that replaces paper has to be easy to learn. In-app tutorials, LiveChat, a HelpCrunch help center and help videos were how they got unstuck without waiting on email. If your users aren’t technical, plan for support as part of the build, not as something you add after the reviews come in.

What this means if you’re hiring someone to build your app

A few things from PMU Forms apply to most first versions:

• Pick the one moment that has to work. Here it was the client signing on the device. Everything else came second.
• Use managed services for the generic parts. Auth, storage and hosting are solved problems. Your budget should go to the part that’s specific to your business.
• Write down what you’re not building yet, and why. Editable templates came years after launch. Keeping features like that out of a first version is how you get to six weeks instead of six months.
• Decide how you’ll get paid. A subscription built into the app meant every artist who kept using it was paying for it.
• Let paying users set the roadmap. The 2022 survey told us more than any guess we could have made up front.

How working with me goes

I work the way I did on PMU Forms. We start by agreeing on the problem and the one flow that has to work. I tell you plainly what I think should wait, and why, so the timeline is something you chose and not something that happened to you. You see working software early and often, not a big reveal at the end. And I treat the business side, how users pay and how you’ll support them, as part of the build.

I offer three packages:

• Prototype in a week for $2,500, to test an idea with real users.
• MVP in about 8 weeks from $15,000, for a first version you can launch and charge for.
• Monetization audit for existing apps, $750, if you already have an app and it isn’t earning what it should.

You can read the short version of this project on the PMU Forms case study page. If you have an app you want built, get in touch or book a free 30-minute call and we’ll talk through what your first version should be.