Senior Full-Stack Developer Needed to Stabilize & Complete SipVault / Document & Form Management System

I have an existing SaaS application called SipScale that is already substantially built in Replit/React/TypeScript with an existing backend, database, authentication, and document/form functionality.

I am looking for an experienced full-stack developer to take ownership of three interconnected areas of the application and get them working correctly and reliably:

SipVault, Admin Document Hub, and Admin Form Configuration.

This is not a greenfield build and not a redesign project. The UI/design direction already exists. The problem I need solved is the underlying architecture, data relationships, configuration logic, and end-to-end functionality so I am not continually fixing one screen only to break another.

The developer should first audit the existing implementation and understand the current data model before making changes.

The core requirement is that these three areas operate from one canonical source of truth.

SipVault is the customer-facing document/compliance repository.

It must use exactly these seven categories:

Company & Ownership
Financial & Tax
Federal & Regulatory
State Licensing
Insurance
Distribution
Brands & Products

There should not be duplicate or competing category structures elsewhere in the product.

Each SipVault requirement/document needs to know things such as its category, state if applicable, agency if applicable, requirement name, related official form if applicable, completion/status information, customer document, available actions, and configuration established by the admin.

Every document/requirement must have a deterministic primary action such as:

Apply Online
Prepare Form
Upload
View
Review Form

It can also have configured secondary actions in the ... menu.

Those actions cannot be independently hard-coded in multiple front-end components.

Document Hub should be the administrative control center for the requirements/documents that appear in SipVault.

An admin needs to be able to create and edit the requirements, assign them to one of the seven canonical SipVault categories, associate a state where appropriate, associate government forms/resources where applicable, configure the primary action and overflow-menu actions, and control what customers ultimately see in SipVault.

Changes made here must reliably propagate to SipVault without creating duplicate records or separate versions of the same requirement.

Form Configuration controls how official forms are prepared using information stored elsewhere in SipScale.

The admin should be able to select an official form, see the form's fields in their proper order, map those fields to Business Profile data, mark fields as system-generated, ask-during-preparation, mapped, etc., save the configuration, and later use that saved configuration when a customer selects Prepare Form.

A form should maintain its relationship to the appropriate SipVault requirement/document.

I need the developer to make the entire workflow work end-to-end:

Admin configures requirement → requirement appears correctly in SipVault → customer chooses an action → correct upload/application/form-preparation workflow opens → saved data/status/document updates → SipVault and readiness/status information update accordingly.

Important architectural requirements

I do not want three independent pages that merely look correct.

I want the underlying system cleaned up so there is:

One canonical requirement/document model
One canonical seven-category taxonomy
Stable IDs and relationships between requirements, forms, uploaded documents, states, and configurations
No duplicate records created simply because the same requirement appears in multiple views
Server/database-backed configuration rather than important behavior living only in UI state
Correct tenant/customer scoping
Existing authentication/security preserved
Existing production services reused rather than replaced unnecessarily
Database migrations handled properly
Validation/error states
No silent save failures
No hard-coded demo data
No toast-only mutations that do not persist
Responsive existing UI preserved
Existing functionality outside this scope not broken
Form Configuration requirements

The form configuration system is especially important.

I need a durable mapping structure so an admin can configure, save, reopen, modify, and use a form repeatedly.

For each form field, the system should support states such as:

Mapped to Business Profile
Suggested mapping
Needs setup
Ask during Prepare Form
System generated

Saved mappings must actually drive the customer's Prepare Form experience and resulting form output.

The solution should be extensible so adding another government form later does not require creating custom application logic for every individual form.

What I expect before major coding begins

I do not want someone immediately making random UI edits.

First, review the repository and provide a short technical assessment covering:

Current architecture
Relevant database tables/schema
Existing APIs/services
Current SipVault implementation
Current Document Hub implementation
Current Form Configuration implementation
Duplicate/conflicting data models you find
Root causes of current problems
What should be retained
What should be refactored
Proposed canonical data model
Proposed implementation sequence
Risks/migration considerations

After we agree on the approach, implement it.

Definition of done

This project is complete when I can test the system as both an admin and a customer and the following works without manual database fixes:

Admin

Create/edit a SipVault requirement
Assign its canonical category
Assign state when applicable
Associate an official form
Configure actions
Configure form mappings
Save everything successfully
Reopen the configuration and see the saved values
Make edits without creating duplicates

Customer

See the correct requirements in SipVault
Filter/use the seven categories
See applicable state requirements
See the correct primary button
See the correct ... menu actions
Upload a document
Prepare a configured form
Reopen/review a prepared form
See status update correctly after an action is completed

System

Data persists after refresh/logout
Tenant data remains isolated
No duplicate requirements/forms are created
No broken references
No browser-console/server errors during normal workflow
Existing application functionality remains intact
Desktop/tablet/mobile layouts remain functional

I also expect automated tests around the important data and workflow logic, not just visual QA.

Technology / experience desired

Strong experience with:

React
TypeScript
Node/full-stack TypeScript applications
PostgreSQL / relational database design
SaaS multi-tenant architecture
Form/document workflow systems
Schema migrations
API design
Authentication/authorization
Existing-codebase refactoring
Testing and debugging

Experience taking an AI/vibe-coded application and stabilizing it into a maintainable production architecture is a major plus.

Important

Please do not apply if your approach is primarily to patch individual React components until each screenshot looks correct.

The visual designs largely already exist.

I am specifically looking for someone who can understand the system as a whole, determine why SipVault, Document Hub, and Form Configuration keep becoming disconnected, and fix the architecture and implementation so they remain synchronized going forward.

In your proposal, please include:

Examples of similar SaaS systems you have stabilized or refactored.
Your experience with React/TypeScript/Postgres.
Your approach to auditing an unfamiliar existing codebase before modifying it.
How you would prevent three interfaces like these from drifting apart.
Whether you recommend hourly or milestone pricing for this project.
Your hourly rate.
Your estimated range of hours after an initial code audit.
Whether you personally will perform the work or subcontract it.

Preferred experience with CRM, ERP, and form configuration/preparation from uploaded items.

Please begin your proposal with the words “CANONICAL DATA MODEL” so I know you read the full description.