The Paradox Process and Anpa
- Role
- SEO, Full-Stack Developer & Technical Director
- When
- June 2024 — June 2026
- Stack
- Next.js
- React
- TypeScript
- Stripe
- Zoom
- Neon
- PostgreSQL
- ComfyUI
At The Paradox Process, I was the sole web developer on the team. I also managed social media for several months during my time there; this article focuses on the web-development work.
The monthly problem
The first thing I noticed when I started at The Paradox Process was how much time they were losing to routine tasks. One of their products is a series of classes called the Manifesting Lab. To facilitate it, each month a staff member would create a new Thinkific course, a sales page, a Keap form, and a Keap automation. This process took about an hour and created unnecessary opportunities for human error.
My initial remedy was a sales page that could be updated through a password-protected admin portal. Payments were facilitated with Stripe, and on completion of a transaction the application sent contact data to Keap, including the class schedule and the customer's selected classes as custom fields. Through this method, I was able to automatically send customers emails based on the classes they had signed up for. This was certainly an improvement, but I still felt there was work to be done.
Prototype — custom public site
Before — Thinkific public pageDrag the slider, or use arrow keys. The prototype is still viewable at the archived Vercel preview.
Where the stack stopped fitting
One issue I could not get around was access control. The Paradox Process used a single link for all of its classes, relying on the honor system and hoping customers would only join the classes they had paid to attend. I wanted to resolve that with custom fields, but I could not make Keap reliably model and govern a unique, per-purchase class-access link across the team's existing automation setup without creating a brittle campaign structure.
I felt this was a fundamental mismatch between The Paradox Process's business model and the way its Keap setup worked, so I began building a custom course-operations and contact-management system. That work later became known as Anpa.
Building Anpa
I created a public API and several important integrations for Anpa. Its Zoom integration provisioned a custom link for each class a customer purchased. Through those individualized links, we could automatically record attendance and gauge the audience's interest in each class topic. Its Vimeo integration automatically uploaded class recordings when classes ended, so customers could receive the video-on-demand version of the class they had paid for as quickly as possible.


While Anpa worked well and saved the staff at The Paradox Process a lot of time, I realized as I began looking for other roles that I had created a situation where I would have to provide technical support for the platform indefinitely if anything came up.
Making the handoff
When my time ended at The Paradox Process, I made sure to transition the team back to the older systems they were more comfortable with, systems that had large dedicated support teams. I did not want to leave them in a position where they would have to hire a web developer whenever the staff had a question or issue with the platform.
This ultimately taught me a valuable lesson: for non-technical people, comfort with a tool is one of the most important factors determining whether they will be able to use it effectively. That comfort does not come from flashy new features or even from productivity gains. It comes from stability and the ability to get support when needed.
While my platform was a better fit for The Paradox Process on paper, I would never be able to match the support system around a product like Keap. Switching back was the right call.
The original custom site prototype can still be viewed at the archived Vercel preview. Anpa's current reference build is Wellspring: a fictional course business that can be explored as a guest, learner, or admin.