Holofante started with a practical constraint: grow an R&D lab without hiring an administrative layer. Proposals, contracts, billing, approvals, and delivery status were spread across conversations and tools. Each new project created more coordination work.[1]
The answer was to treat the operation as a product. The system connected the quote-to-cash lifecycle to a shared project state, so clients and the studio could see what had happened, what was blocked, and what action came next.
DesignOps as infrastructure
The first decision was to build a multi-state component framework instead of project-specific screens. The same interface could represent a paused project, a client action, an approval, an error, or an offline fallback. This made the system consistent across the eight project milestones and reduced the cost of creating new workflows.
The second decision was to render the interface from its states. Proposal, contract, payment, and delivery determined which component and action appeared. A signed contract could unlock the next step without another page or manual update.
Automation with boundaries
Notion became the source of truth for project records, while Node.js serverless functions connected it to payments, signatures, notifications, and client-facing views. UUIDs and encrypted sensitive fields kept proposal values out of guessable public URLs.
The system was intentionally built inside the existing JavaScript ecosystem and under real client work. That constraint favored small, composable automations over a large platform rewrite.
Holofante grew MRR by 340%, recovered more than ten hours per week, and supported twelve simultaneous projects. The result was not only faster administration: it gave a service business a repeatable operating model where design, engineering, and operations shared the same states.
Solo project: Lio Schimanko was the only person involved and worked as the solo founder. âŠī¸
