From Supabase Prototype to Production: Fractional CTO Leadership for an NIL Athlete Platform
The Prototype Was Already There
AI has changed who can build software.
A product owner who understands their domain and feels its problems firsthand can now turn that knowledge into a working application faster than ever. In many cases, the domain expertise is now the scarcer resource, not the engineering.
This engagement was another chance to work with exactly that kind of team.
The client knows the NIL market (Name, Image and Likeness, where athletes monetize their personal brand) deeply. They understand the athletes, the business relationships and the operational pain, because they live it every day.
They had already started building on their own. When they came to us, they brought a working prototype built on Supabase. It proved the idea and reflected a clear understanding of what the product needed to do.
Then they made a decision we often see experienced founders make.
Before going further, it had to be done the right way from the very beginning.
The objective was not simply to make the prototype work in production. It was to build a foundation the business could grow on:
the right architecture;
security built into the foundation, not added later;
a structure that can scale and support the business as it evolves.
AI makes it possible to generate code faster than anyone can review it. We wrote about that already here. A prototype built at that speed is a great starting point, but not a production foundation.
That is where our work started.
As their Fractional CTO (a part-time technical leader who takes responsibility for technology decisions without a full-time hire), we took ownership of the technical direction and the first production release. One of our senior engineers implemented the system alongside us.
The First Decision: We Didn't Start with Features
With a working prototype on the table, the obvious move was to start from what was already there.
Polish the screens. Fix the bugs. Add the missing features. Ship.
We deliberately didn't.
A prototype is valuable evidence of what the founders need. But it is not a specification. It contains the idea, mixed together with every shortcut and assumption made along the way.
Building production software directly on top of it would have carried those assumptions into the foundation.
So we started with a different question.
Not "What features should we build?" but "What business are we in?"
Conceptually, our specification follows a chain, where each step builds on the one before:
Business Context
Problem Domain
Domain Model
System Responsibilities
Functional Requirements
Architecture & Technical Design
Validation (PoCs)
Roadmap & Delivery
Business Context
The first step was understanding why the system exists at all.
Why does the system exist?
Who are the stakeholders?
What business outcome are we trying to achieve?
What are the business processes and constraints?
This is where the client's domain expertise was most valuable. They already knew the answers. Our job was to ask the right questions and capture the answers precisely.
Problem Domain
Next, we worked through the real-world problem the business solves, before any software.
We identified the actors, roles, concepts, events, rules and relationships. We also defined a shared vocabulary (often called the ubiquitous language: one set of terms used by the business, the engineers and the code). Every core business term means the same thing to the founders, to us and later in the codebase.
Just as important, we separated what is truly part of the problem from implementation assumptions that had crept in through the prototype.
Domain Model
From there, we built a conceptual model of the business:
the information the business works with and how it relates;
the distinct areas of responsibility (bounded contexts: parts of the business that have their own rules and language);
how business processes move through those areas;
the rules that must always hold true.
This model became the backbone of everything that followed and gave the founders something concrete to sign off on before any implementation started: not tasks or designs, but a shared understanding of how their business works.
Sign-off is a business decision, not a technical formality. We wrote about why founders should never skip it here.
Image Source: Photo by Jeremy Thomas on Unsplash
A Short Detour: Value Chain and Business Capabilities
Before moving from the domain to the system, it is worth zooming out once more.
A domain model tells us how the business works. But it does not tell us where the business creates value, or which parts of it deserve the most attention.
For that, we use two simple tools.
The Value Chain
A value chain (the sequence of activities through which a business turns its work into value for its customers) shows the business as a flow, from the first contact with a customer to the moment value is delivered.
It separates two kinds of activities:
Primary activities, which directly create and deliver value to customers;
Supporting activities, which make the primary ones possible, such as administration, finance or compliance.
Looking at the business this way quickly shows which activities actually make the company different and which ones every company has.
Image Source: here
Business Capabilities
A business capability describes what the business does, not how it does it or who does it. Examples are "manage customer relationships" or "process payments."
Capabilities are stable. Teams, processes and tools change over time, but what the business needs to be able to do changes much more slowly. That makes capabilities a much better foundation for software than screens or features.
Why This Matters for the System
Put together, the value chain and the capability map answer questions that a feature list never will:
Which capabilities are core, the ones that make the business unique and deserve the best design and engineering?
Which are supporting, needed but not differentiating?
Which are generic, solved the same way by everyone and better bought or integrated than built?
This directly shapes the next step. Core capabilities become the heart of the system and get the most care in the domain model. Generic ones are often best left outside the system boundary and connected through integrations.
The objective is not simply to build everything the business does. It is to invest engineering effort where the business actually creates value.
From Domain to System
Only once we understood the business did we start talking about the system.
This changed the conversation. Instead of debating screens and features, we could reason about responsibilities.
Drawing the System Boundary
Not everything in the domain belongs in the software.
We decided explicitly what the platform should own, what belongs outside it, and where it must integrate with external actors and services.
Only then did we define what the system is responsible for.
Specifying Behavior
Next, we turned the domain into capabilities and use cases.
Where precision mattered, we described behavior as concrete scenarios in Gherkin (a structured Given / When / Then format that both business people and engineers can read). Each scenario specifies inputs, outputs, rules, state changes and what happens when things go wrong.
These scenarios are readable by the founders and precise enough to test against. We wrote about turning them into automated Playwright tests here.
Architecture & Technical Design
Then we mapped the domain onto software components, separating concerns across layers:
presentation;
application and cross-cutting concerns;
domain;
data;
platform;
infrastructure.
Supabase was already the platform, and it is a strong one. But the objective was not to fit the business into Supabase.
Every architectural decision was made because of the domain, not the other way around.
We see the opposite mistake often: a team chooses a technology first and then bends the business to fit it.
Data access rules, security boundaries and the data model were all derived from how the business actually works. Clear areas of responsibility keep data isolated and prevent the database from becoming a big ball of mud, which we described here. Row Level Security (database rules that decide which rows each user can see) is designed to stay correct and fast as the data grows. You can read why that matters here.
Alignment: Giving Founders the Right Tools to Communicate
Communication and founder engagement decide the outcome of most software projects.
Founders are rarely the problem here. They know their business better than anyone. The problem is that they are very often not given the right tools to communicate it.
In a typical project, founders explain their business in meetings, emails and chat messages. The development team turns that into tasks and estimates. Somewhere between the two, context is lost, and nobody notices until the software behaves differently than expected.
We wrote about this "telephone game" and why founders should never skip a proper sign-off here.
Spec Structures the Founders Could Confirm
In this engagement, the specification itself became the communication tool.
We took everything we learned about the client's business and put it into clear spec structures: the business context, the domain model, the shared vocabulary and the behavior scenarios. Each of them was written in business language, not technical language.
This changed the nature of the conversation.
The founders were no longer asked to approve tasks or technical decisions they could not fully evaluate. They were asked a much simpler question: "Is this how your business works?"
And they could answer it with confidence.
Where something was wrong or missing, it was corrected in the specification, before a single line of production code depended on it.
Interactive Mockups: The Final Piece of Alignment
Some things are hard to confirm on paper, even for founders who know their business deeply.
So the final alignment was achieved by adding a few interactive mockups (clickable prototypes of key screens that behave like the real application, without a working backend).
The objective was not simply to show what the application would look like. It was to let the founders walk through real business scenarios and react to them.
Conceptually:
Business understanding
Spec structures confirmed by the founders
Interactive mockups of key scenarios
Early feedback
Final alignment
Production development
The mockups gave us early feedback at the cheapest possible moment, when a change costs minutes instead of days.
With the specification confirmed and the key scenarios validated, there was nothing left to guess. We could start moving the prototype into production with the founders and the engineering team pointing in the same direction.
The engagement is still in progress. In our next update, we will share how the release went and what we learned along the way.
In the meantime, if you have a prototype of your own and want to know whether it is ready for production, you can start with our Supabase Security Audit or a free security scan.
Comments