The Lab is built on an intentionally chosen, open stack designed for longevity, ownership, and independence from proprietary platforms. Every technology decision is made so that, at the end of an engagement, you fully own what’s been built and can run, extend, or hand it off without licensing dependencies.
Core stack
Next.js (React) – Primary frontend framework for web apps and marketing sites. The Lab uses Next.js 15 with the App Router for most web-facing products. It’s battle-tested, widely understood, and deployable on many hosts.
Supabase (PostgreSQL) – Database and backend infrastructure, built on Postgres. It’s open-source and self-hostable, and includes authentication, real-time subscriptions, storage, and row-level security. Clients own their Supabase project and all data.
Tailwind CSS – Utility-first CSS framework used on every Lab product. It enables fast development and consistent, maintainable interfaces without CSS bloat.
Astro – Used for content-heavy and marketing sites where performance is critical. It ships minimal JavaScript, yields fast load times, and produces clean static output. The Fulcrum Collective website runs on Astro.
Sanity (headless CMS) – Used when projects need structured content management. The Lab uses Sanity v3 for knowledge libraries, blogs, and product content, leveraging its flexible schema, strong API, and real-time previews.
Laravel (PHP) – Chosen for full-stack backends when products involve complex business logic, multi-tenant architectures, or background processing. It powers Pulse’s application layer.
Why this matters for ownership
All technologies in this stack are open-source or source-available. There are no mandatory ongoing licensing fees that could make operating costs unpredictable, and no proprietary infrastructure that only a single vendor can maintain.
When an engagement ends, you receive:
- The full codebase
- The database schema
- Configuration files
- Documentation any competent developer can understand
You are not dependent on Fulcrum’s proprietary systems, internal tooling, or continued involvement for the platform to function.
What the Lab does not build on
The Lab avoids platforms that create vendor lock-in—where the provider owns the underlying code, data export is difficult, or ongoing licensing makes costs unpredictable. While proprietary platforms can sometimes offer speed advantages, they often compromise long-term ownership.
For the kinds of systems the Lab builds—platforms, intelligence layers, and infrastructure—full ownership and long-term control are prioritized over the short-term speed of proprietary shortcuts.
Related: Do we own the code when done · What the client relationship looks like after launch · How the Lab differs from a dev agency