Moxie's focus on aesthetic entrepreneurs resonates with me because many of its customers are nurses and clinicians taking ownership of their own practices. I build infrastructure so owners can stay focused on their craft.
I look forward to the aesthetics of infrastructure: clean, observable, a pleasure to operate.
01 / the company
The growth is clear. What interests me more is the engineering work underneath it, especially the choices made as Moxie Suite became part of daily clinical operations.
Practices supported. Moxie's current public materials report more than 700 practices, compared with more than 250 at the Series B announcement in September 2024. source 2024 source
Appointments booked. Reported through Moxie Suite in the September 2024 Series B announcement. source
Client-base growth. Software Mansion reports nearly 10x growth within a year. source
Total funding. The March 2026 Series C announcement reports $51 million raised in total. source
Uptime in 2025. Reported in Software Mansion's engineering case study. source
Features shipped in 2024. Moxie tied that output to direct feedback from its medspa partners. source
Titles as of August 2026.
02 / their story
Moxie officially launches, and Moxie Suite launches in October. The company begins with a direct purpose: help aesthetic entrepreneurs build independent practices without carrying every operational problem alone.
Software Mansion builds the Moxie Suite MVP in two months: account management, appointment booking, and pre-appointment forms. The product replaced a collection of disconnected tools with one operating surface. source
A $15.7 million Series A funds expansion. SignalFire and Boulton & Watt lead the round. source
The product adds invoicing with US tax handling, Stripe Connect custom accounts, medical documentation, OTP-protected patient access, signed-URL uploads, and the Good Faith Exam review workflow.
Growth forces measured scale work. The client base grows nearly 10x within a year. The team introduces index-based pagination and virtualization, analyzes Hasura GraphQL output, disables PostgreSQL JIT after measuring query behavior, and moves background work to Celery. source
A $10 million Series B follows. Moxie reports more than 250 supported medspas and more than 200,000 appointments booked through Moxie Suite. source
The team replaces Timekit with a custom scheduler in two months. Software Mansion says the change removed external bugs and reduced debugging time. It also saved thousands of dollars per month.
After critical Fly.io connectivity failures caused hours of downtime, the platform moves to AWS. The case study reports no infrastructure-caused downtime after the move. Datadog supports monitoring, QA Wolf supports automated tests, and Bird Eats Bug supports reporting. source
Compliance Defender enters the product. Its AI checks advertising language for compliance concerns while the broader workflow keeps records and required actions in one place.
A $25 million Series C brings total funding to $51 million. Moxie launches Scale Suite for multi-provider operations and margin intelligence, with AI-guided compliance alerts in the same product. source
Treatment Plans also becomes a public product, embedded in the clinical workflow rather than separated into another tool.
I keep coming back to the scheduler decision. Moxie replaced Timekit with its own in two months, and I am designing and validating the same class of move right now, a Phoenix application migration from Fly.io to AWS Fargate; cutover outcomes are not available yet. Changing vendors does not outsource our responsibility for reliability.
03 / the platform
I read the published stack as a record of practical choices made under real growth and regulatory pressure, with real operating constraints.
Patients access forms through an OTP sent to their phones. Signed URLs let files go directly to storage without making the application server carry the file stream. Those choices reduce exposure at the boundary.
The team disabled PostgreSQL JIT after examining Hasura's generated SQL and query behavior. I admire that kind of decision because it starts with evidence and ends with a smaller system.
Moxie says, "AI supports clinical expertise, it never replaces it." I hold the same line in engineering. The AI tools named in the role, including Claude Code, Codex, Cursor, CodeRabbit, and Glean, match how I already work, with deterministic checks and a person accountable for the result.
04 / the role
My operating thesis is simple: make production changes controlled, observable, bounded, and reversible. That foundation improves flow before the system takes on more complexity.
Own fewer alerts and make each one actionable. Define SLOs around booking, payments, and charting. For me, an SLO earns its place when it changes an engineering trade-off, not when it adds another percentage to a dashboard.
Build once and promote one digest. Branch urgent work from the production revision, while main stays open during deployment.
Use least-privilege and time-bound access. Redact at the source. Treat AI governance as defense in depth, with human approval at the release boundary.
A small platform team multiplies itself when the safest path is also the easiest path. Product engineers should inherit good defaults instead of waiting for a platform engineer to approve routine work.
I studied Moxie's Fly.io to AWS history because I am designing and validating the same class of move right now: a Phoenix application migration from Fly.io to AWS Fargate. Their case study reads like my checklist. The common principle is reversibility first, then speed.
05 / the fit
AI may accelerate the work, but it does not become the authority that approves deployment.
06 / their values
Moxie's values are short and direct. I read them as a test: can I show each one with my own work? Here is my evidence.
Over roughly two months, I paired with a teammate and wrote operational documentation until they could run the system independently. The best handoff is the one where the other person does not need you anymore.
I also share AWS and AI practices with the team on a regular cadence. The pattern outlives the project.
I maintain a personal open-source toolkit built from public and properly attributed components; employer-specific workflows and data stay private.
For a client prototype, I prototyped a Presidio-based PII redaction layer before any model invocation, evaluated against the project's defined PII categories. Data safety was the first requirement, not the last patch.
During an approved infrastructure migration, I consolidated the orchestration footprint and documented the new operating model, so the next engineer could run it without me.
Ownership includes the gaps. I validated the infrastructure code for a cross-region replica, but we never deployed the regional replica, failover automation, or a game day; we had no cross-region DR capability. Owning the outcome includes owning what did not land.
For that migration, I sequenced data, application, and traffic changes separately, and kept a rollback path at every step.
Migration first, modernization second. Fewer variables at cutover.
Care is what makes speed safe: rehearsed rollback, staged exposure, stop conditions before the change starts.
I use two skills that enforce simplicity. ponytail runs a laziness ladder on every coding task: does this need to exist at all, is it already in the codebase, does the standard library do it, can it be one line. The best code is the code never written.
caveman compresses communication to its essentials: code, commands, and error strings stay exact, and security warnings and irreversible actions always get full prose.
I tune their intensity per task, from lite to ultra. Simplicity is a dial, not a dogma.
07 / the conversation
Which three user workflows have the highest revenue and patient-care impact today, and how is their reliability measured?
What does on-call look like today, and how many alerts actually lead to action?
What would make this role successful after six months, and how would the team measure it?