Fresta
Senda
OmniWell
Apps
Fresta, Senda and OmniWell are the current StorySpark products I maintain end to end, from release flow to public support.
I build mobile and web products through StorySpark.
Right now I'm shipping Fresta, Senda and OmniWell, while
keeping the public surface stable for every release.
Read the latest post
Shipping Three Products Without Breaking the Public SurfaceI keep the homepage lean and let each block open into its own page, the same way the reference handles apps and web work as separate surfaces.
Fresta
Senda
OmniWell
Fresta, Senda and OmniWell are the current StorySpark products I maintain end to end, from release flow to public support.
FUT LIGA SC
NeuroPad
This is the operating side of my work: product direction, launch support, frontend craft and the boring-but-critical public routes that keep apps review-ready.
Building the umbrella that holds the apps, the portfolio, the legal routes and the support surface in one coherent system.
A fuller wellbeing product with onboarding, profile structure, communication flows and a visual system built to feel complete.
A spiritual product line built around daily publishing, premium access, content rhythm and a calmer community-facing experience.
Festive calendars, campaign organization and operational clarity for a product that has to feel useful, light and easy to keep fresh.
Privacy pages, data deletion guidance and stable contact routes maintained as part of the product, not as an afterthought.
The stack is intentionally compact. I care more about a tight set of tools that can ship and keep running than an inflated wall of buzzwords.
iOS-first product work with careful flow and polish.
Interfaces, navigation and daily product iterations.
Readable flows, calmer hierarchy and store-ready screens.
Frontend and backend choices for product surfaces that stay stable.
Structured pages, route organization and fast iteration.
Composable UI for product and support-facing surfaces.
Safer iteration for apps, tooling and reusable logic.
Auth, data and product plumbing without unnecessary weight.
Enough design and writing to keep the product voice coherent.
Layout studies, flows and visual refinement before build.
Scope control, feature priorities and public positioning.
Launch notes, blog posts and legal copy with a clear voice.
The small systems that make the visible product reliable.
Predictable containers for the portfolio and support routes.
Subdomain routing and TLS without turning ops into drama.
Source control and deployment handoff for small, fast cycles.
Privacy and deletion routes shaped as product infrastructure.
The reference also had a writing layer, so this portfolio now does too: a small set of posts around shipping, public surfaces and product decisions.
Latest post
What changes when you stop treating release notes, legal pages and support routes as admin work and start treating them as product.
Read postNew note
A short note on why these pages influence trust, review stability and the feel of the whole product.
Read postBuild log
Why I prefer a smaller system where apps, portfolio and support surface evolve together instead of drifting apart.
Read post