fracxional.
Fractional CTPO for messy real-world operations.
Chief Technology + Product support for founders who need product judgment, technical architecture, and hands-on execution without a full-time executive hire.
How I work
From vague bottleneck to operating system.
The diagnostic turns ambiguous product, tooling, and workflow problems into a practical execution path: what to build, buy, automate, stop, and measure.
- 1
Diagnose the operating reality
- 2
Decide what deserves to exist
- 3
Build the production loop
- 4
Make it operable without us
Product direction
Clarify what should exist, who it serves, and which decisions need to be made now.
Production build
Turn the chosen direction into a working product, integration, or operating system.
Operable handoff
Leave ownership, documentation, metrics, and a cadence the team can continue.
Selected work
Proof before capability lists.
Zero-to-one product builds
Product direction, architecture, and hands-on delivery from blank slate to production.
Technical DD & advisory
Architecture risk, AI feasibility, and build-versus-buy judgment before the expensive decision.
AI systems for operations
Practical automation, agentic workflows, and guardrails built around how the team actually works.
Systems
Reusable products shaped by delivery.
Patterns that earned a name by solving the same operating problem more than once.
View all systemsFounder-led
“I shape what should exist, then build the system that makes the work run.”
I'm Shen Nan: former startup CTO, product engineer, and technical operator. I've built from a blank slate, worked inside fast-moving organizations, and inherited the workflows nobody wanted to untangle.
When the work calls for it, I bring a trusted bench of product, design, and ML specialists.
Notes from the work
Ideas earned in delivery.
Build Log
Build log 001: from services to systems
A repositioning pass that removes the generic consultancy shape and makes work, method, systems, and operating ideas the primary surface.
Essay
The system starts before the software
Most software failures begin one layer earlier: an unclear decision, a missing owner, or a workflow nobody has modelled honestly.
Start a conversation