Peavox: Building a Fitness SaaS MVP as a Solo Founder
TL;DR
Peavox is a fitness business management SaaS platform built from the ground up as a solo founder project. By leveraging a modern tech stack (Kotlin/Spring Boot, React Native/Expo, Next.js) and making deliberate architectural decisions around multi-tenancy, type safety, and cross-platform development, the entire platform, including backend API, mobile app, admin portal, and marketing website, was built and launched by a single developer.
Introduction
Building a SaaS product typically requires a team: backend developers, frontend specialists, mobile developers, and DevOps engineers. But with the right technology choices and architectural decisions, a solo technical founder can build a production-ready platform that competes with products built by much larger teams.
Peavox is a fitness business management platform that helps gym owners and fitness studios manage memberships, schedule courses, handle bookings, and process payments. The challenge was to build all of this, with proper multi-tenant architecture, native mobile apps for both iOS and Android, a full admin dashboard, and a marketing website, as a one-person operation.
Technical Architecture
Monorepo Structure
The entire platform lives in a single monorepo, enabling atomic changes across the stack, shared tooling, and simplified deployment:
peavox/
├── backend/ # Spring Boot API (Kotlin)
├── mobile-app/ # Expo React Native (TypeScript)
├── admin-portal/ # Next.js dashboard (TypeScript)
└── website/ # Astro marketing site
Technology Choices
| Component | Technology | Why |
|---|---|---|
| Backend | Kotlin + Spring Boot | Type safety, null safety, mature ecosystem |
| Mobile | React Native + Expo | True cross-platform, rapid development |
| Admin Portal | Next.js | Server-side rendering, React ecosystem |
| Marketing Site | Astro | Static generation, minimal JavaScript |
| State Management | TanStack Query | Server state sync, caching, optimistic updates |
| Validation | Zod | Runtime validation with TypeScript inference |
Key Technical Challenges
Challenge 1: Multi-Tenant Data Isolation
Problem: Each fitness business needs complete data separation while sharing infrastructure.
Solution: Implemented SiteContext as a request-scoped component. All database queries are automatically scoped to the current tenant. This isn’t just a convention; it’s enforced at the architecture level. Every repository query (except admin operations) must be tenant-scoped, and this is validated in integration tests.
The result: fitness businesses can trust that their member data, booking history, and financial information is completely isolated from other tenants.
Challenge 2: Cross-Platform Mobile Development
Problem: Native mobile apps for iOS and Android are expected, but building and maintaining two separate codebases as a solo developer isn’t feasible.
Solution: React Native with Expo provides true native performance with a single TypeScript codebase. Combined with TanStack Query for server state management and Zod for validation, the mobile app shares patterns and even some code with the admin portal.
The repository pattern organizes all data fetching logic, making it easy to add features without creating spaghetti code. When a gym member books a class, the same patterns handle loading states, error handling, and cache invalidation whether they’re on iOS or Android.
Challenge 3: Type Safety Across the Stack
Problem: API contract mismatches between backend and frontend cause bugs that are hard to catch until runtime.
Solution: Type safety is enforced at every layer:
- Backend: Kotlin’s null safety and DTO pattern for all API request/response bodies
- Frontend: TypeScript throughout, with Zod schemas that provide both runtime validation and TypeScript type inference
- Testing: MockMvc controller tests catch integration issues early
When an API contract changes, TypeScript compilation fails in the frontend before any code reaches production.
Core Features Delivered
Member Management
- Member profiles and contact information
- Membership plan assignment and tracking
- Status management and history
Course & Scheduling
- Course creation and configuration
- Session scheduling with capacity management
- Recurring schedule patterns
Booking System
- Real-time availability checking
- Member class bookings with confirmations
- Waitlist management
Payment Processing
- Stripe Connect integration for embedded payments
- Automated billing and invoicing
- No sensitive payment data stored (Stripe handles PCI compliance)
Results
Solo Founder Efficiency
The combination of:
- Monorepo: Single source of truth, atomic changes
- Type Safety: Reduced debugging time, caught errors at compile time
- Modern Frameworks: Production-ready foundations out of the box
- Repository Pattern: Organized code that’s easy to maintain
…enabled a single developer to build what would typically require a team of 4-6 engineers.
Production-Ready Architecture
Unlike many MVPs that accumulate technical debt from day one, Peavox was built with:
- Multi-tenancy as a core design principle, not an afterthought
- Clean separation of concerns enabling future scaling
- API-first design ready for third-party integrations
- European compliance (GDPR, SEPA support planned)
Technical Differentiators
| Aspect | Legacy Fitness Software | Peavox |
|---|---|---|
| Architecture | Monolithic legacy systems | Modern, microservices-ready |
| Mobile | Web wrappers or dated apps | True native cross-platform |
| API | Closed or limited | Open API design from day one |
| Multi-tenancy | Bolted-on | Designed from ground up |
| Payment Integration | Custom processors | Stripe Connect (portable) |
Lessons Learned
-
Invest in type safety upfront. The time spent on Kotlin + TypeScript + Zod pays back quickly in reduced debugging and increased confidence when making changes.
-
Multi-tenancy must be architectural. Adding tenant isolation to an existing system is painful. Building it in from the start is relatively straightforward.
-
Modern tooling multiplies solo developers. Expo, Next.js, and Spring Boot provide so much out of the box that a single developer can focus on business logic instead of infrastructure.
-
The monorepo enables agility. When a feature requires changes across backend, mobile, and admin portal, making them in a single commit with a single CI/CD pipeline removes coordination overhead.
Conclusion
Building a SaaS product as a solo founder is challenging, but it’s increasingly viable with modern tooling. The key is making smart architectural decisions early: choosing type-safe languages, designing for multi-tenancy from day one, and leveraging frameworks that handle infrastructure concerns.
Peavox demonstrates that with the right technical foundation, a single developer can build a platform that’s not just an MVP hack, but a production-ready system that can scale with the business.
Visit peavox.com to learn more about the platform.