SCRIPE
I started SCRIPE because running a sports academy should not require a spreadsheet, a chat app, a booking tool and a separate admin system just to understand one day of work.
I’m building SCRIPE as one operating system for the business and coaching work around a sports academy, with football as the first deep vertical.
Why I started it
The problem was fragmentation. Scheduling, memberships, staff, facilities and coaching information tend to live in different places, so the academy never really sees one operation. I wanted the product model to join those workflows instead of adding another isolated tool.
What I own
I’m the founder, product/technical architect and primary developer. I make the product calls, design the system boundaries and work across the .NET backend, Next.js surfaces, Flutter coach app and the developer tooling around them.
The product underneath the football vertical
Football is the first deep vertical, but it sits on a real horizontal foundation. The backend already has modules across identity, organization, HRMS, analytics, pricing, communication, compliance, facilities, media, scheduling, entitlements and integrations. The goal is reuse where the business is common, and depth where the sport is specific.
One ecosystem, several surfaces
The backend owns business rules and authorization. The web surfaces handle administration and operations. The coach app is being built for the pitch-side workflow. Dev Tools and the public site solve different problems again. I keep them separate because their users and failure modes are different.
Where it is now
The platform foundation, major backend modules, web work and developer tooling are substantial and active. The coach app has a strong application foundation but is still moving toward the complete football workflow. I keep shipped work and product direction separate on purpose.
Back to all work
Work index ↗