Why move beyond Airtable
Creators Pro coordinates content production between creators and operational teams: requests, media delivery, editing, approval and preparation for publishing. Airtable had helped us implement the first workflows and validate them with a small group of internal users.
As requirements evolved, its interfaces became a constraint. Finding ways around those limits often took more work than the feature itself; tracing errors in the system we had built was also difficult. We needed more control over data, application logic and interfaces, with a structure suited to the product’s growth.
From product knowledge to React
I contributed from the start by helping colleagues understand the product rules: how users worked, which steps were expected and which rules from the iOS app and Airtable flow needed to be preserved.
To contribute to the frontend, I chose to learn React and adapt to the site’s existing stack. I gradually moved into web development, initially working on editing views, filters and clip grouping. Alongside the frontend, I worked on the module’s APIs and evolving data model.
A gradual transition for teams
The product was still used internally. We chose to build the new stack without importing historical Airtable data. Both workflows initially remained active, and teams moved to the new platform gradually through onboarding.
The module evolved from Projects and Edits to Approvals and Vault, with changes to Collections and the introduction of Requests. As features grew, the relationship between the original request, media and subsequent work needed to stay clear.
Restructuring data and workflows
In the July 2026 restructuring, I independently designed and implemented the data model, APIs and interfaces for Edits, Approvals and Vault, together with the required PostgreSQL migrations.
I introduced a shared Asset model connecting source and derived media to production requests, editing and review. Workflow activities gained their own entities and statuses while retaining references to the request and content involved.
This work also had to account for data already present in the new system. I handled migrations and backfills to adapt relationships and statuses to the new domain. This was an evolution of the PostgreSQL platform already in use, following the earlier move from Airtable.
Stages of the same request
The goal of unifying Requests, Edits and Approvals was to present activities as stages of the same request. Users needed to move comfortably between steps while keeping the content’s context. Connecting content to Social Metrics to assess its performance was another product goal.
The lead product designer gave us clear direction on UI, UX and the goal to achieve. Within the team’s implementation, I handled the links between detail screens and the API information needed to navigate between stages.
The APIs expose the original request, the associated editing work and approval status. Interfaces can then show the expected stages, which are available and which are complete, while respecting the user’s permissions.
Designing Planning with the team
For Planning, the team was given a goal to achieve. Drawing on my product knowledge, I worked out a data organisation, proposed it to colleagues and refined it through discussion. I then communicated the shared decisions to the project manager.
The model includes a base template per creator, account customisations, recurring weekly schedules and exceptions for specific dates, with content types and quantities. The initial implementation was shared across the team: my contribution at that stage was defining and discussing the proposal for data and APIs.
I later also worked on connecting Vault content to planning and reusing it in slots. This linked the data structure to operations on content that was already available.
The result
The work supported teams’ gradual move to a platform with data, APIs and interfaces maintained by the development team. The module connected content production and management stages, continuing to evolve while in use.
For me, it meant expanding my contribution from the iOS app to the web product: first sharing domain knowledge, then working directly across React and the backend, and eventually independently designing and implementing a restructuring across the stack.
Technical details
The diagram shows the content’s logical path. Editing and approval stages depend on the workflow required for each request.
- Request and media
- Editing, if required
- Approval, if required
- Vault
- Planning
The request remains the reference for workflow activities and media. Planning organises work on content; connecting to Social Metrics was a further product goal.
Two distinct transitions
The move from Airtable did not import its historical data. July’s migrations and backfills instead handled data already in PostgreSQL, adapting it to the new production, editing, review and media entities.
Media and workflow activities
The shared Asset model connects sources and derivatives to the request, editing, review and content to publish. Approval events retain references to the media involved, preserving the context of each activity.
Existing data compatibility
Migrations update domain names, relationships and statuses. For promoted content linked to clips, the backfill retains existing units and moves their reference to the parent request; explicit checks stop the migration when media belongs to incompatible requests.
State-driven navigation
The workflowNavigation contract brings together the original request, editing and approval requirements, associated editing work and review counts. The frontend builds detail navigation from this information and permissions: stages that are not required are omitted, and unavailable stages cannot be opened.
Planning rules
An account uses its own template when configured; otherwise it inherits the creator’s base template. The model distinguishes recurring days from exceptions for specific dates. PostgreSQL constraints enforce uniqueness for active templates and daily configurations; APIs expose each account’s effective configuration.