A Spanish-first company-operations product combining a customer dashboard, an internal operations queue, and 6+ connected services.
sanitizedProduct interface with personal details removed.
At a glance
What I owned
Period
February 2024 to present; independent and concurrent with Acelera since January 2026
Role
Co-founder; product and full-stack engineering
Team
Founder-led product and operations team
Users
LATAM founders and the operations team supporting them
Status
Live company-operations product
Contribution
Mapped provider states into one order model and built the founder dashboard, internal queue, and integrations with Kotlin/Spring Boot and PostgreSQL.
Tradeoff
Combine provider updates into clear customer actions while preserving the operational checks needed before filings, payments, and other sensitive changes.
Evidence
Public Rely site, sanitized product surfaces, and documented service integrations.
Role
Product + full-stack engineering
Integrations
6+ connected services
Frontend
React + TypeScript
Backend
Kotlin + Spring Boot
State model
One order, two working views
Provider-specific states are translated into one formation order. The same order drives a clear next action for the founder and an exception queue for operations.
Provider signals
FIFiling accepted
KYIdentity pending
BKBanking review
DCDocument ready
ILLUSTRATIVE ORDER STATERLY-XXXX
Company filed
Next required action: verify the beneficial owner.
Customer state
Action required
Internal owner
Onboarding
Source
3 provider events
Founder viewOne next action
Upload identity document
Operations queueException with context
Owner · source · due date
01
The operating constraint
A formation order moves through filings, banking, documents, payments, deadlines, and support. Each provider reports state differently. Founders need a useful answer to one question: what happens next?
02
One company, two working views
I designed the shared state model, founder dashboard, and internal queue. Customers see progress and required actions. Operators see ownership, provider state, documents, exceptions, and the context needed to act.
realPublic pricing and service configuration.
sanitizedFounder dashboard with personal details removed.
03
Make the next action visible
The shared order connects customer context, missing documents, provider state, and required actions. Sensitive changes stay behind explicit approval.
04
What is running
The frontend and admin tools connect to Kotlin and Spring Boot services, PostgreSQL, Auth0, Stripe, document storage, formation providers, and 6+ connected services.
recreatedThe running control plane around one persistent formation order.
05
Observed result
Founders can inspect formation progress and required actions. Operators work from a shared queue with provider state, documents, and visible approval boundaries.
recreatedTwo product views supported by shared company state.
