How we built Physician.me, from idea to launch

Note: Sadly, I had to shut down my start-up 1 year ago for personal reasons. This article was originally published in April 2023.

I am equal parts excited and nervous to introduce my new company to the world. It’s been 6+ months from idea to launch, and now the time has come!

It’s like sending your kid to school for the first time. Are they ready? Have I done enough to prepare them? Will other people actually like them?

Embarking on the journey to launch a new product / company takes a leap of faith that you will find a way to solve a lot of problems that you don’t even know exist yet. This creative problem-solving is serious fun! Because it’s so fun, because what I did might help you — and also because I’ve been working as a solo founder and I need someone to celebrate with — I want to share with you how I approached it.

Also, make sure you check out physiciancompany.com to see what it’s all about.

Decision to bootstrap

I worked in a venture-backed start-up (@SukiAI) for the 5 years prior to starting The Physician Company. It was a great ride, and I loved our investors. But this time, for a couple of reasons, I wanted to do things differently.

First, my objective is to build something quickly that connects me with physicians as customers. Software is great that way — you can build and ship a simple but useful product without too much expense. The sooner I can put a product in users’ hands and get feedback, the faster the conversation starts between us. Learning from our physician-users will determine what happens next with our company.

I don’t want to start with a big, hairy problem that requires tons of time and capital to solve. I admit everyone loves a big, hairy problem and the inspiring vision that comes with solving it — including me! So I’ll say it now and then leave it alone: The Physician Company is here to empower doctors. We believe in restoring the balance of power in medicine to favor doctors in service of patients.

But the starting point for us should be small. I intend to focus on a simple, contained problem that connects me to users — a scale of problem that doesn’t require venture-scale funding.

Second, I like the simplicity and control of working for myself. Once you take outside capital, there is an obligation to steward the capital well. At this stage, I prefer to focus on my obligation to customers exclusively.

What to build

I started out knowing which customers I wanted to serve, and how I wanted to build my company. I rolled those criteria around in my head for a while until I came to a problem I could solve, and a simple product to address the problem.

That product is Physician.me, an application for storing and tracking a physician’s professional credentials, for example their medical license and DEA certificate. It’s a need I saw in my own life. I had a personal experience where I let my DEA expire on accident, and it was a huge hassle — so one feature of Physician.me is, it will send reminders when expiration dates are approaching.

I figured that (to paraphrase something smart I read on Twitter) if I can build something I want to use, all I have to do is figure out how to reach more people like me!

Operating framework

Once I had made the decision to start, I put together a framework for operating. The framework kept me moving toward the big picture goal, while focusing day-to-day on the tactical details that would get me there.

I used an OKRs framework. I started by assigning a high-level theme to each of my first 4 quarters. The themes helped me focus on solving 1 problem at a time, and avoid trying to solve everything at once.

My quarterly themes were:

1. Set up business operations

2. Kick off product workstream

3. Kick off distribution workstream

4. Launch (and learn)

I accepted this high level set of objectives as a set of boundaries, for pacing myself. Then going into each quarter, I would create more detailed OKRs around that quarter’s theme. After I planned out the quarter’s activities, I would go heads-down executing on what I had planned.

Here’s how it went, and what I learned.

Q1: Set up business operations

The 2 real activities of any business are building and selling. That said, to enable real work, you have to set up an administrative framework — a way to pay for things, send email, etc.

In the first couple months, half my focus was on setting my Suki colleagues up for success in my new strategic advisor role. During that time, I made a lot of progress on administrative items. I established the following:

• LLC
• Tax ID number
• Mailing address
• Bank account
• Company name
• Website domain(s)
• Google Workspace
• Decided on various other software vendors (Yes to Confluence, No to Slack)
• Created a spending forecast and budget

Each of these steps in itself was pretty straightforward. The one challenge was the dependencies between some of the steps — especially company name + domain availability.

I had to learn a bunch of ins-and-outs, and I feel that knowing those details will serve me, so I’m glad I didn’t spend money on a third party to do the work for me. For example, what are you allowed to call your company when it’s a California LLC? It turns out there are some constraints, which I got around by filing a Fictitious Business Name statement.

I funded the LLC bank account with an initial budgeted amount, and committed to staying disciplined about budget and keeping the accounting clean. I was then ready for the real work to begin.

Q2: Kick off product workstream

Building a software product requires design and engineering. I hired contractors for both roles, and I played the product manager role myself.

I was clear in my mind about the critical importance of great UX design. The UX designer, in this case, would also have a hand in defining brand identity, since the look and feel of the product would spill over into the brand.

I wrote up a product definition, drew some rough UX flows, and created a spreadsheet with a list of features. Then I went on UpWork and similar sites, and interviewed 10 UX designers. I learned a lot about what I was looking for during the interviews themselves. Based on conversations with designers, I answered questions like:

• What design software to use? (Figma)
• What’s more important to spend my budget on, a design system or full-featured UX flows? (Both, but keep it simple)
• Whether to use Google’s material design versus designing custom icons and other components? (Custom in our case — although more effort for developers to implement, it gives Physician.me a distinctive and thoughtful feel)

The effort of talking to 10 designers was totally worthwhile. I found someone great on my 10th interview. He is opinionated, detailed, and shares my view that simple is beautiful.

We worked on UX flows together for a couple weeks. We then used prototyping software to send the designs to a dozen friendly doctors, get their feedback, and make adjustments.

Next, I set out to find an engineering partner. I had worked with a company called Symphony IS before, and I evaluated them and one other contract development firm recommended by a friend. It helped tremendously that I was able to show clearly documented UX flows in Figma. The firms used that, along with my roadmap spreadsheet, to estimate the work required to build the product.

I will highlight that I chose my software development partner based on quality more than price. Symphony IS employs smart, ownership-minded engineers in Eastern Europe. My team, based in Belgrade, was composed of a fullstack developer, a program manager, and a quality engineer.

We built Physician.me as a web application and used Firebase services whenever possible. Assembling pieces from Google’s “backend as a service” saves a lot of time and resources over reinventing the wheel, for example on things like user authentication. Firebase also has extensions available for common third-party integrations, such as Stripe for payments.

The stack for our web app includes the following:

• Firebase authentication
• Firestore database and Google cloud storage
• Stripe for subscription payments, via a Firebase extension
• Twilio and SendGrid APIs for SMS and email messaging
• Google Cloud functions for a custom Reminders service
• Google Analytics and Big Query for data analysis

Another great thing about Firebase is that when we build a mobile app, the backend will be all set to support it.

Overall, it took us about 3 months of development effort to build / assemble the Physician.me product. We completed the vast majority of the features we planned for the initial launch, with a few trade-offs as we learned and adjusted priorities. Most importantly, the product was built with attention to quality: simple, scaleable engineering architecture, security, user experience, and fidelity to the UI design.

I am very proud of this product. As with any early product, there will be gaps, and we will learn and fill them as we go. This is the great fun of launching software into the world — it’s never done. Now it’s ready for its first users!

Q3: Kick off distribution workstream

With product development well underway, I turned my attention toward how to reach customers.

I had a lot of different workstreams in play at this point: business operations, design, engineering, and now marketing. It would have been a lot if I had tried to figure it all out at once, but because I had created a roadmap that layered in these workstreams over a few quarters, it felt manageable. The product work was in an execution phase rather than a definition phase. The only undefined work was marketing.

Brand work — including logo, colors, company name, web domains — had already made a bunch of progress due to product and administrative dependencies. The next big item was the public website.

I tasked myself with finding a contract firm to build the site, physiciancompany.com. Not having built a marketing website before, I pinged a few friends to understand their experience. Some friends warned me off hiring a contractor and suggested I do it myself with a web builder. But I was too new to this domain, and I wanted a partner.

I interviewed 4 or 5 different kinds of contractors to understand the options. For example, should I:

• Work with a marketing design firm versus a more technical web development contractor?
• Go with Wordpress versus a web builder, versus build a custom html site?

I chose to work with Olive Street Design, a marketing design firm, leveraging a web builder called Duda. My reasons were:

1) Not having marketing experience myself, I wanted a marketer as a partner.

2) The web builder seemed ideal for site maintenance by a relatively non-technical person (myself).

3) User experience begins with site performance including loading speed, and Duda (like Squarespace and similar offerings) performs well versus the alternatives.

In the end, I found myself being very directive with the web designers. But in their defense, I more or less expected this. Reaching an audience of physicians is something I need to figure out myself. It’s the key unknown in this company — how to build a brand that speaks to physicians?

I have to speak in my authentic voice, which is the voice of a colleague and peer.

Along those lines, a core aspect of our outreach strategy is high-quality site content, namely our blog. The public website isn’t just a vehicle to promote Physician.me — the site establishes the identity of The Physician Company. It puts a stake in the ground that says we are here for you, as a company, whether or not you find our product(s) useful. I wanted to create content on the website that would be freely available and helpful to doctors — particularly those at the center of our target market, those just finishing training and starting their first attending job.

I am grateful to Mike Scahill, a friend and pediatrician who has helped put together the initial blog articles for the site. These are not articles that ChatGPT could write! Mike’s lived experience and passion for teaching comes through in a way that makes me very proud of the blog.

One last piece of this puzzle, before the website could launch, was legal. We needed a website privacy policy and terms for use. This was a little more challenging than expected! I wanted these documents to represent the quality of the company, our product, and our regard for our users.

To get that kind of quality, you can’t use off-the-shelf legal templates. After a few false starts, I was lucky to find a boutique technology law firm, Kelly & Simmons LLP. They also happen to be a women-owned firm and strong supporters of women entrepreneurs. I am looking forward to working with them again.

Q4: LAUNCH! (and learn)

Now we are ready for the fun(nest) part.

Shipping a product is about making sure all the threads come together. You can allow loose ends — for sure, there will be long-running threads that we don’t want to wrap up yet, as this is just the beginning. But you can’t allow any critical loose ends.

I am so eager to tell the world that The Physician Company is here. I’m excited to try some ideas for reaching doctors with our value proposition, and start finding out what works. I’m super excited for the dialogue with users to begin.

Before telling the world, it pays to double- and triple-check on polish items for a high quality launch. Some examples of polish items include:

• Getting feedback from a few friendly users to flush out any avoidable gaps or hiccups
• Exercising the processes for engineering support, so they’re well-established when we really need them
• Ensuring the website gets indexed by Google
• Setting up analytics so we can track user activity and learn
• Polishing the blog
• Filling out social profiles
• Neurotically clicking on all the buttons and links so you make sure leads / users are landing where you want them to

I’m also acutely aware that perfection can be the enemy of progress. As the product manager, I am making trade-offs between completeness and timing. You have to make the cut at some point. There will always be a next release, and opportunity to iterate.

The most important aspect of a product launch is to be ready to learn and adjust. Don’t hold onto your convictions too tightly. Collect data and be ready to change your mind.

At the same time, as a founder, I know better than to take feedback too literally. Users can only react to what they can see concretely. They can’t see your vision. This is the perpetual balancing act of product leadership — let data change your mind, but also have steadiness in your conviction. When you get feedback from users, always ask why. Often there is more insight in the “why” than in the surface-level feedback.

Here we go!

When I started out on this journey, I created a 4-quarter company roadmap to serving our first users. We are nearing the end of that roadmap with our upcoming launch, and I am now planning for the next year ahead.

I learned from a mentor to set goals aiming for the stars, so that when you fall short, you still land on the moon. In that spirit, I’ve set a 2023 goal for user growth, and I’m not going to share it with you! Because with no past data, it’s a silly goal and it’s sure to be either too high or too low. But in the early days of a company, the goal-setting exercise itself has merit. It lays groundwork for how a company operates and measures its progress.

I am really hopeful that doctors — particularly young doctors who are transitioning from training programs to their first attending roles — will find our product useful. I hope they adopt it and the company sees some early revenue.

More than that, I hope:

1. Doctors see The Physician Company as a company built to serve them.
2. They try out the product and give us feedback on what could make it better, and what else we could build that would add value to their lives.

Being pragmatic, I am also eager to get some market validation of the direction we’ve chosen. That validation will give us the conviction to build more.

I am so extremely proud of the product and brand that we are introducing this month. Just like when my kids started kindergarten, I know there is a long way to go from here, and lots to learn! This is a beginning. Before we get to the end, it will take on a life of its own.

If you read this far, I hope this was helpful or entertaining or both! I’d love to hear your thoughts, questions, and feedback.